CQRS(Command and Query Responsibility Segregation)与EventSources实例

cqrs

      the cqrs pattern and event sourcing are not mere simplistic solutions to the problems associated with large-scale, distributed systems.

从1000万用户并发修改用户资料的假设场景开始

1. 每次修改操作耗时200ms，每秒5个操作
2. mysql连接数在5k，分10个库
3. 5 *5k *10=25万tps
4. 1000万/25万=40s

在秒杀场景中，由于对乐观锁/悲观锁的使用，推测系统响应时间更复杂。

使用actor解决高并发的性能问题

1000万用户，一个用户一个actor，1000万个内存对象。

200万件sku，一件sku一个actor，200万个内存对象。

平均一个sku承担1000万/200万=5个请求
1000万对数据库的读写压力变成了200万
1000万的读写是同步的，200万的数据库压力是异步的
异步落盘时可以采用批量操作

总结：

由于1000万+用户的请求根据购物意愿分散到200万个商品sku上：每个内存领域对象都强制串行执行用户请求，避免了竞争争抢；内存领域对象上扣库存操作处理时间极快，基本没可能出现请求阻塞情况；

从架构层面彻底解决高并发争抢的性能问题。理论模型，tps>100万+……

eventsourcing：内存对象高可用保障
actor是分布式存在的内存状态及单线程计算单元，采用eventsourcing只记录状态变化引发的事件，事件落盘时只有add操作，上述设计中很依赖actor中state，事件溯源提高性能的同时，可以用来保证内存数据的高可用。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－

今天先到这儿，希望对您技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管理,团队建设 有参考作用 , 您可能感兴趣的文章:
前端性能核对表checklist-2018




微服务与docker介绍
docker与ci持续集成/cd









精益it组织与分享式领导











it基础架构规划方案一(网络系统规划)



供应链需求调研checklist

如有想了解更多软件设计与架构, 系统it,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：petter liu
出处：
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-petter liu blog。