排队（顺序消费）+Group commit

 

阿里早期开源过一个mysql的分支alisql，他有一个特性特别吸引人，支持在mysql 引擎层对单条数据的修改进行排队的功能。这个特性能给我带来什么样的好处呢？比如我们现在有一个需求要做微博点赞量的计数器，在不用redis缓存相关技术，基于现有的技术很难做到高性能。而alisql为我们考虑的这个问题，mysql我们都知道如果一条记录存在同一个时间非常多线程去更新的时候性能非常的差。列出一个测试数据：mysql 5.6 版本，8个线程同时更新一条记录的TSP大概是4.3k，当加大512个线程去更新这个记录是他的TSP只有143，造成这个问题的原因就是锁导致的。alisql巧妙的通过在引擎层增加了一个排队机制，从而避免锁的问题。根据原来的一个测试数据他们可以做到单台服务器的更新Tps可以做到1.5W。针对计数器、商品秒杀、点赞量这种需求还有进一步优化的空间。就是引入Group commit的技术，比如ABC三个用户同时分别对某个微博进行点赞，我们可以在数据库层合并这三个请求为一次更新的请求，在Innodb层我们只需要做一个操作即可。假设我们group commit的size最大为100，周期为10毫秒，当10毫秒size超过100立即提交，又或者等待超过10毫秒，只要size大于0也立即提交。根据阿里丁奇的PPT数据报告上说，他们的通过这个手段让商品的库存扣减TPS从原来的1.5w提升到8.5w。这可以说是一个非常恐怖的数字。通过一下的测试效果来说这是一个非常好的功能特性，他能帮我们解决好多类似这样的问题，不过mysql官方好像并未接纳这个提交。alisql也已经好几年为维护了。作为一个小型的公司基本是不敢在生产环境上这一套，基本不具备去修改他的能力，更别说在数据库上增加一个排队机制和group commit。不过他的解决问题的思路还是值得我们去借鉴的排队+group commit的技术。之前学习的CQRS框架也用到了类似的解决方案，Event Sourcing 存在一个不足就是事件特别多，每一个操作都产生一个事件然后在存储事件，当并发量上去了，我们一样也会碰到类似问题，为了避免这个问题，在CQRS架构中，通过聚合根的顺序消费 + Group commit批量保存event的解决思路。 这也是CQRS实现高性能的重要手段之一。
具体聚合根的顺序消费+event的group commit 后续在详细介绍。

 

下面图附是上mysql 和alisql的一个压测数据报告，大家可以详细对比一下

具体测试数据来源阿里的测试报告

https://github.com/alibaba/AliSQL/wiki/AliSQL-Performance-benchmark-for-inventory