Featured Article

关于平台构建以及编程语言说明

个人简介 来自 2019年3月31日 下午6:27 发现自己很久没有更新博客的板式了,还是最初折腾了好多次再就没有更改,现在的主题倒是挺好看的,而… Read More »

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 值。当哈希冲突发生时,一般有以下几种方式来处理:

分布式锁实践中的一些坑及优化手段

当微服务由单机部署变为分布式集群部署,在业务中涉及的一些数据库操作或者其他可能存在并发问题的地方,都有可能因为代码层面考虑不周或存在漏洞,导致数据丢失更新,数据不一致的问题发生,我也是在工作中遇到这个问题。例如A请求查询数据库中可用次数为100,此时B请求也查询数据库中可用次数为100,A请求进行-1之后在数据库中修改为99,而B请求也-1之后修改数据库中可用次数为99,这时就发生了数据丢失更新的问题,给公司造成了损失,当并发量更大,B请求出现一定延时,可能会发生其他请求已经修改了十多次,而B请求又将可用次数改为99,如此日积月累会造成巨大的损失。

我由幻读而明白了数据库事务

innodb更加完美的解决了幻象问题,在默认情况下设置为REPEATABLE-READ的隔离级别即可,事务级别越低涉及到的锁越少,虽然REPEATABLE-READ级别会将Record Lock升级为Next-key lock锁,但并不会比READ-COMMITTED级别有性能损耗。