Java知识星球

所需数据 首先需要将所有需要合并的文件转换成字节流也就是byte[] 然后把，每个数据都放到一个list 文件路径转换成byte[] 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354final List<String> collect = //你的文件路径集合logger.info("开始转换pdf");int totalUrls = collect.size();int batchSize = 20; // 每批文件数量int totalBatches = (int) Math.ceil((double) totalUrls / batchSize); // 共多少批任务if (totalBatches <=0 ) return new byte[0];ExecutorService executorService = //你的自定义线程池List<CompletableFuture< ...

Idea推送Github仓库超时问题 有时候在本地推送Github的仓库的时候经常Time OUT 并且你挂了梯子之后还是会超时，这个时候只需要配置一下终端代理就行 寻找终端代理的 找到梯子的终端代理端口号然后替换掉下边指令的 1export https_proxy=http://127.0.0.1:33210 http_proxy=http://127.0.0.1:33210 all_proxy=socks5://127.0.0.1:33211 或者找到您对应的梯子的可视化界面复制终端代理的代码 配置终端代理 打开git bash 输入终端代理的代码 最后打开Idea重新推送代码就可以了

RabbitMQ如何保证消息幂等？ 1、生产端做消息幂等 (即不重复投递) 在生产端的话，其实消费端做好幂等，生产端就算投递多次，也无所谓了。 如果实在想在生产者做幂等的话，可以参考消费端的思路，比如通过redis的 setnx (key可以设计成 producer:具体业务:具有唯一性的某几个或者某一个业务字段 作为key) ,添加防重表等等。但是我个人觉得没必要。把消费端做好幂等就可以了。 2、消费端做消息幂等 (即不重复消费) A、方案 1234567891011121314151617181920 /** * 是否能消费，用于防止重复消费 * false 代表未消费过 ，true代表消费过 * * @param content * @param queueName * @return */private Boolean checkConsumedFlag(T content, String queueName) { String messageKey = queueName + ":" + conten ...

消息手动ack + 手动重试 1234567891011121314151617181920212223242526272829303132333435363738394041/** * 消息最大重试次数 */private static final int MAX_RETRIES = 3; /** * 重试间隔(秒) */private static final long RETRY_INTERVAL = 5; private static final ObjectMapper OBJECT_MAPPER = new ObjectMapper(); @RabbitListener(queues = RabbitMqConfig.USER_ADD_QUEUE, concurrency = "10")public void userAddReceiver(String data, Message message, Channel channel) throws IOException, InterruptedException { UserVo ...

ElasticSearch和Kibana配置 1、docker-comppose 1234567891011121314151617181920212223242526272829303132elasticsearch: container_name: gw-es image: registry.cn-hangzhou.aliyuncs.com/zhengqing/elasticsearch:7.14.1 volumes: - ./elasticsearch/config/elasticsearch.yml:/usr/share/elasticsearch/config/elasticsearch.yml - ./elasticsearch/logs/elasticsearch.log:/usr/share/elasticsearch/logs/elasticsearch.log - ./elasticsearch/data:/usr/share/elasticsearch/data #配置文件挂载 - ./elasticsearch/plugins:/u ...

数据库和缓存Redis的一致性问题无论在面试还是平时使用的时候都是一个很常见且关键的问题这里我写一篇文章记录一下 Cache-Aside 旁路缓存模式，应用最为广泛的一种缓存策略。 读请求 首先查询redis查看是否存在，如果存在的话直接返回数据，如果不存在查询数据库，然后写入缓存 写请求 直接更新数据库然后删除缓存 为什么先更新数据库，而不是先删除缓存 因为在并发的情况下如果线程A先去删除缓存然后线程B去查询了数据K，此时线程B查询了数据K，并且将数据写入了缓存，然后线程A才去更新了数据库，然后此时我们的缓存就会是一个旧数据所以不能先删除缓存 在这种情况下怎么解决缓存一致性的问题呢 由于先删除缓存后更新数据会有缓存脏数据，所以业内又提出了延时双删，也就是在删除数据之后，更新数据库，防止别的线程读取了数据产生了脏缓存延时之后再进行一次删除，这个延时的时间一般稍微大于业务的读时间耗时，但是无论这个值如何预估，都很难和读请求的完成时间点准确衔接，这也是延时双删被诟病的主要原因。 先更新数据之后再删除缓存就没有问题了么 肯定不是的，在读写并发的时候也是会出现数据不一致的问题的，下面列举一 ...