服务频繁发生YoungGC的处理过程（合理压测）
最近一直在做项目的GC优化，因为服务在运行过程中频繁发生GC问题，虽然不是FullGC，但Young频繁GC也会影响线上服务的性能，优化的方向有两个，1.修改JVM参数 ，2.优化代码逻辑。查看当前线上JVM配置调整年轻代的大小可以缓解因内存分配太小而发生频繁GC的问题。本次优化的重点在于代码逻辑的实现，
Author Archives: wcy
无状态节点服务的缓存数据同步实现
在目前需求背景下要设计一套底层服务系统，提供一系列基本数据请求接口，这里把该系统服务称为P，为保证高可用高可靠性，P系统最少依赖外部中间件，例如数据库消息队列等组件，服务所涉及的数据全部缓存到本地缓存中，然后由其他服务来请求接口或数据库收集数据，将收集的数据存入Redis中，再去通知P系统更新本地缓存的数据，收集数据的服务称为D。
MySQL与Redis中对LRU算法的使用
LRU也称为最近最少未使用算法，作为最常用的内存淘汰算法，在主流的系统中都可以见到相应的使用场景，而在MySQL与Redis中也有使用，可以说都是用来对存储空间进行管理，及时淘汰更新数据，提高存储空间利用率。
mysql自动合并索引(index merge)查询导致死锁问题
虽然在生产环境上加了分布式锁，但还是会出现某一个事务未结束，而下一个事务进入来修改数据，这时就会陷入等待，最后等待超时，事务进行了回滚，在运行几个月后第一次出现这种情况，发生死锁的是两条update语句，当sql语句的where语句中使用两个索引时，mysql的优化器可能会对这两个索引进行合并，使用explain分析会显示Using intersect(index1,index2); 表示将index1和index2合并来查询。该表中只有index1,index2两个索引。
缓存数据一致性如何保证
最近在思考的一个问题，如何保证缓存和数据库数据的一致性，防止出现类似于余额这种数据，在缓存里是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 结构实现的。
Kafka涉及到的多种选举机制
提起Kafka中的选举，第一印象肯定是broker节点之间的选举，它依赖于Zookeeper来进行选举，其实还有partition之间也有选举，以及其他地方都存在选举，但这些都是由Kafka内部完成，它们都需要一个leader来把控全场，由leader来负责读写请求，处理消息的同步，监听分区变化，监听主题变化，保存一些分区方案，记录消费位移等信息。我总结的有以下几种选举。
使用CyclicBarrier控制Kafka多线程消费消息的位移提交问题
Kafka中消费者是线程不安全的，一个topic只能被一个消费组中的消费者消费，想要提高数据消费能力，可以增加分区数，因为消费者数可以和分区数进行对应，当消费者数大于分区数时，多余的消费者将处于空闲状态，或者也可以在每个线程中创建一个消费者实例，这样也可以对数据来处理，但创建多个消费者实例必然会造成资源的浪费。通过线程池来对数据进行消费，就会存在位移提交的问题，从而引发数据丢失或重复，所以对位移的提交要格外处理，消费者默认是定时提交位移信息的，如果需要手动提交，要先修改配置参数关闭自动提交，再通过代码里调用commitSync()方法。
从TheadLocalMap看哈希碰撞后开放寻址法的实现过程
本来想说ThreadLocal，但看到了ThreadLocalMap中对哈希碰撞是采用开放寻址法来实现的，觉得很有意思，hash使用的场景很多，散列表就是一种高效而常用的数据结构，能将查找的时间复杂度降到O(1)，它通过哈希函数来生成一个 hashcode 值，从而对数据进行一一定位，虽然现在的哈希函数已经能做到很好的随机，但还是会有冲突发生，也就是不同的对象经过哈希函数的计算，生成了相同的 hashcode 值。当哈希冲突发生时，一般有以下几种方式来处理：