当微服务由单机部署变为分布式集群部署，在业务中涉及的一些数据库操作或者其他可能存在并发问题的地方，都有可能因为代码层面考虑不周或存在漏洞，导致数据丢失更新，数据不一致的问题发生，我也是在工作中遇到这个问题。例如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级别有性能损耗。
Kafka中消费者以消费组的形式存在，消费组来消费每个主题中分区的数据，因为主题中的分区数和消费者数量并不一一对应，这时候就涉及到如何为每个消费者分配分区，而当有消费者在中途退出时，就会触发再均衡的发生，再重新为剩余的消费者分配分区。每个消费组在服务端对应一个GroupCoordinator对其进行管理，而消费者客户端中的ConsumerCoordinator组件负责与GroupCoordinator进行交互，它们负责执行分区的分配，以及消费者再均衡的操作。
注册中心是用来集中管理微服务，实现服务的注册，发现，检查等功能，目前比较成熟的注册中心组件有很多，如Consul，eureka，zookeeper，etcd，nacos，不同组件之间性能，并发，高可用都会有差距。但对于用户来说基本的功能实现都是透明的。其实如果我们自己开发一套注册中心也可以，能够满足基本的功能即可。
在业务场景中有一个需要定时15分钟后取消用户订单的功能，可以使用Java的任务调度框架来实现，但还需要引入框架依赖和设置数据表等，对业务的侵入性很大，有点大材小用的感觉，所以这里使用延时队列就可以，Kafka本身是不支持延时队列的，需要在生产消息和消费时进行一些二次开发，以下是我对该业务具体实现的思考。
大部分组件是基于磁盘存储的，但由于CPU速度和磁盘速度之间的鸿沟，都会使用缓存技术来提高性能，缓存简单来说就是一块内存区域，首先将从磁盘读到的数据放在缓存中，之后查询或修改时直接操作缓存，对于缓存中的数据则以一定的频率刷新到磁盘上，怎样缓存，缓存多少，何时刷新，这些影响着整个组件的性能。在看过一些关于mysql等组件的架构原理后，会发现不论是基于磁盘的mysql数据库和Kafka消息中间件zookeeper分布式协调框架，还是基于内存的redis数据库，它们都设计了完善的内存和磁盘之间数据交互实现。
在去除原有synchronized单机锁后，在关键步骤添加分布式锁来对具体业务进行锁定，然而由于锁定范围大，导致锁竞争增加，不断发生锁等待，如果不进行优化，可能会让线程队列增大甚至阻塞，而且在等待时长超过设定的阈值时，线程将超时返回。
引入主从架构，数据读写分离，目的是为了解决业务快速发展，请求量变大，并发量变大，从而引发的数据库的读瓶颈。不过当引入新一个架构解决问题时，势必会带来另外一个问题，数据库读写分离之后，主从延迟从而导致数据不一致的情况。
这个问题是在一次面试的时候面试官问的，当时确实懵了，只能模糊的去描述zookeeper关闭后的kafka 状态，自己并不非常肯定，回来之后一直想亲自试验一下，今天刚好搭了一个单节点的Kafka和单节点的zookeeper，之后有时间再去分别测试集群版环境的响应情况。
重写的六大风险 因最近一直在重写公司一套系统，看到这篇文章时觉得说得很好，里面的观点和建议说得非常有价值，值得… Read More »