AlgoRain的博客

在开发过程中经常会用到线程池，但创建线程池的方法都比较简单，使用Executors来创建相应功能的线程池，常用的方法有这些。1、 Executors.newFixedThreadPool(int nThreads);创建固定大小(nThreads,大小不能超过int的最大值)的线程池2、Executors.newSingleThreadExecutor()：创建大小为1的固定线程池。3、Executors.newCachedThreadPool()；创建corePoolSize为0，最大线程数为整型的

Java8中的抽象类和抽象接口区别首先,一个类只能继承一个抽象类,但是一个类可以实现多个接口其次,一个抽象类可以通过实例变量(字段)保存一个通用状态,而接ロ是不能有实例变量的熟悉Java或者看过Java面试题的都知道，Java不支持多继承，原因是:安全性的考虑，如果子类继承的多个父类里面有相同的方法或者属性，子类将不知道具体要继承哪个。Java提供了接口和内部类以达到实现多继承功能，弥补单继承的缺陷。所以在实际开发中可以通过多个接口来灵活实现，但Java8中支持接口编写默认方法，变相等于可以

这篇文章主要是提供一种转发路由的代码实现方式，之前说的gateway都是使用配置文件来对请求进行路由，这样虽然很简单，但是不够灵活，如果后端对应很多服务实例，网关想要根据自己的规则来转发请求，比如编写不同的负载均衡策略，做一些特别的权重，以及在运行过程中动态的变更转发地址，这些用配置文件来做都不够灵活，没法自由的定义规则。涉及的gateway版本 <dependency> <groupId>org.springframework.cloud<

问题描述最近一直在做项目的GC优化，因为服务在运行过程中频繁发生GC问题，虽然不是FullGC，但Young频繁GC也会影响线上服务的性能，优化的方向有两个，1.修改JVM参数 ，2.优化代码逻辑。查看当前线上JVM配置调整年轻代的大小可以缓解因内存分配太小而发生频繁GC的问题。本次优化的重点在于代码逻辑的实现，主要原因是：在目前架构内，系统并不能通过改变eden区大小得到有效解决，年轻代内存区域调大，GC频率改善，但时长会变长。反之，作用也是相反。频繁的GC和pause清理耗时又引起jvm内

在目前需求背景下要设计一套底层服务系统，提供一系列基本数据请求接口，这里把该系统服务称为P，为保证高可用高可靠性，P系统最少依赖外部中间件，例如数据库消息队列等组件，服务所涉及的数据全部缓存到本地缓存中，然后由其他服务来请求接口或数据库收集数据，将收集的数据存入Redis中，再去通知P系统更新本地缓存的数据，收集数据的服务称为D。以下为P，D，Redis关系图。需要注意的是，P并不会强依赖与Redis与D系统，因其本地缓存有一份全量的数据，只是对数据的实时性不能保证，要靠D系统来定时发送更新通知，本

MySQL与Redis中对LRU算法的使用LRU也称为最近最少未使用算法，作为最常用的内存淘汰算法，在主流的系统中都可以见到相应的使用场景，而在MySQL与Redis中也有使用，可以说都是用来对存储空间进行管理，及时淘汰更新数据，提高存储空间利用率。Redis内存淘汰机制在redis.conf中有一行参数用来配置内存淘汰策略的maxmemory-policy volatile-LRUvolatile-LRU：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的

mysql自动合并索引(index merge)查询导致死锁问题虽然在生产环境上加了分布式锁，但还是会出现某一个事务未结束，而下一个事务进入来修改数据，这时就会陷入等待，最后等待超时，事务进行了回滚，在运行几个月后第一次出现这种情况，发生死锁的是两条update语句，当sql语句的where语句中使用两个索引时，mysql的优化器可能会对这两个索引进行合并，使用explain分析会显示Using intersect(index1,index2); 表示将index1和index2合并来查询。该表中只有in

缓存数据一致性如何保证最近在思考的一个问题，如何保证缓存和数据库数据的一致性，防止出现类似于余额这种数据，在缓存里是1，而数据库修改为0后，用户再次发起扣费操作时，由于每次先会去判断缓存内余额的数据，缓存数据不一致，导致本应失效的一次请求被判断通过。这种情况在并发低的时候不太容易产生，当并发增大极有可能发生。我在项目中主要靠两种方式来保证数据一致性：数据必须设置随机过期时间缓存数据最重要的目的是提高数据查询速度，在第一次查库之后将数据放入缓存，之后直接从缓存里拿数据即可，所以缓存数据的持久化并不

MySQL查询缓存与Innodb引擎的自适应哈希索引查询缓存执行过程MySQL与引擎之间更像是两套体系，相互之间协同提供更好的数据服务，查询缓存是MySQL在8.0版本之前提供的一个特性，当客户端与数据库连接完毕，需要执行查询语句时，查询缓存就会发挥作用，MySQL会将查询语句进行对比，如果之前执行过该语句，执行语句和执行结果会以键值对的形式被直接缓存到内存里，因为使用查询语句作为key，MySQL可以用语句来查询对应的key，在缓存中找到的话，就可以将key对应value的值返回给客户端，少去了后来

Hash底层存储原理及优化Redis中big Hash的一些建议Hash 是 Redis 中出现最为频繁的复合型数据结构,除了 dict 结构的数据会用到Hash外,整个 Redis 数据库的所有 key 和 value 也组成了一个全局Hash,还有带过期时间的 key 集合也是一个Hash。set集合相当于一个value为null的Hash，zset 集合中存储 value 和 score 值的映射关系也是通过 hash 结构实现的。由于业务上考虑不周，使得生产环境中有一个hash结构存储的数据量达

Kafka涉及到的多种选举机制提起Kafka中的选举，第一印象肯定是broker节点之间的选举，它依赖于Zookeeper来进行选举，其实还有partition之间也有选举，以及其他地方都存在选举，但这些都是由Kafka内部完成，它们都需要一个leader来把控全场，由leader来负责读写请求，处理消息的同步，监听分区变化，监听主题变化，保存一些分区方案，记录消费位移等信息。我总结的有以下几种选举。broker Leaderpartition LeaderGroupCoordinator Lea

使用CyclicBarrier控制Kafka多线程消费消息的位移提交问题Kafka中消费者是线程不安全的，一个topic只能被一个消费组中的消费者消费，想要提高数据消费能力，可以增加分区数，因为消费者数可以和分区数进行对应，当消费者数大于分区数时，多余的消费者将处于空闲状态，或者也可以在每个线程中创建一个消费者实例，这样也可以对数据来处理，但创建多个消费者实例必然会造成资源的浪费。通过线程池来对数据进行消费，就会存在位移提交的问题，从而引发数据丢失或重复，所以对位移的提交要格外处理，消费者默认是定时提交位

从TheadLocalMap看哈希碰撞后开放寻址法的实现过程本来想说ThreadLocal，但看到了ThreadLocalMap中对哈希碰撞是采用开放寻址法来实现的，觉得很有意思，hash使用的场景很多，散列表就是一种高效而常用的数据结构，能将查找的时间复杂度降到O(1)，它通过哈希函数来生成一个 hashcode 值，从而对数据进行一一定位，虽然现在的哈希函数已经能做到很好的随机，但还是会有冲突发生，也就是不同的对象经过哈希函数的计算，生成了相同的 hashcode 值。当哈希冲突发生时，一般有以下几种

分布式锁实践中的一些坑及优化手段记录使用分布式锁时网上其他文章没有谈及的性能和优化问题，切勿生搬硬套网上代码。本文仅讨论使用Redis作为分布式锁，不考虑Redis其他一些问题，如是否为单机节点，怎么做主从集群或者哨兵，与Zookeeper和其他分布式共识算法实现的分布式中间件有什么区别，我选择redis主要还是考虑它自身的性能和编码的复杂度，至于CP还是AP的选型暂时不作为考量标准。当微服务由单机部署变为分布式集群部署，在业务中涉及的一些数据库操作或者其他可能存在并发问题的地方，都有可能因为代码

我由幻读而明白了数据库事务刚开始接触数据库事务的时候，总会被脏读，不可重复读，幻读，读未提交，读已提交，可重复读等等这些“读”名词整的特别混乱。只能去硬记数据库事务的级别，以及每个级别可以解决的问题，和不同数据库实现的事务级别，直到后来彻底看完innodb引擎对事务的处理，才算彻底理清这些事务之间的关系，当别人再问起来时，可以马上根据底层原理说清楚与理论的关系。本文中还是以innodb引擎为例来进行说明，其他数据库或引擎所知甚少就不谈及了。简单的说事务就是保证一组操作要么全部成功要么全部失败，提到事务

Kafka中再均衡的发生过程Kafka中消费者以消费组的形式存在，消费组来消费每个主题中分区的数据，因为主题中的分区数和消费者数量并不一一对应，这时候就涉及到如何为每个消费者分配分区，而当有消费者在中途退出时，就会触发再均衡的发生，再重新为剩余的消费者分配分区。每个消费组在服务端对应一个GroupCoordinator对其进行管理，而消费者客户端中的ConsumerCoordinator组件负责与GroupCoordinator进行交互，它们负责执行分区的分配，以及消费者再均衡的操作。目前在以下几种情况

浅析微服务注册中心的注册与发现注册中心是用来集中管理微服务，实现服务的注册，发现，检查等功能，目前比较成熟的注册中心组件有很多，如Consul，eureka，zookeeper，etcd，nacos，不同组件之间性能，并发，高可用都会有差距。但对于用户来说基本的功能实现都是透明的。其实如果我们自己开发一套注册中心也可以，能够满足基本的功能即可。支持IP端口的注册：注册中心提供接口将服务发布者的信息添加进去。提供一些其他信息，如服务名称，只注册IP仅能实现基本功能，如果需要加密或者负载均衡时，如

Kafka实现订单超时取消的两种模拟策略在业务场景中有一个需要定时15分钟后取消用户订单的功能，可以使用Java的任务调度框架来实现，但还需要引入框架依赖和设置数据表等，对业务的侵入性很大，有点大材小用的感觉，所以这里使用延时队列就可以，Kafka本身是不支持延时队列的，需要在生产消息和消费时进行一些二次开发，以下是我对该业务具体实现的思考。1.建立不同时间区间的topicKafka内部有很多延时性的操作，如延时生产，延时拉取，延时数据删除等，这些延时功能由内部的延时操作管理器来做专门的处理，其底层是

对于mysql，redis，Kafka，zookeeper磁盘缓存技术使用分析大部分组件是基于磁盘存储的，但由于CPU速度和磁盘速度之间的鸿沟，都会使用缓存技术来提高性能，缓存简单来说就是一块内存区域，首先将从磁盘读到的数据放在缓存中，之后查询或修改时直接操作缓存，对于缓存中的数据则以一定的频率刷新到磁盘上，怎样缓存，缓存多少，何时刷新，这些影响着整个组件的性能。在看过一些关于mysql等组件的架构原理后，会发现不论是基于磁盘的mysql数据库和Kafka消息中间件zookeeper分布式协调框架，还是基

今天更新了VisualVM 2.0.5，启动的时候提示找不到jdk引用，于是到包内部的visualvm.conf中修改jdk引用地址。visualvm.conf的路径/Applications/VisualVM.app/Contents/Resources/visualvm/etc/visualvm.conf将visualvm_jdkhome修改为类似以下的路径就可以了visualvm_jdkhome="/Library/Java/JavaVirtualMachines/jdk1.8.0_181.