从1000万用户并发修改用户资料的假设场景开始
在秒杀场景中，由于对乐观锁/悲观锁的使用，推测系统响应时间更复杂。
使用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
如有想了解更多软件设计与架构, 系统it,企业信息化, 团队管理 资讯，请关注我的微信订阅号：
![megadotnetmicromsg_thumb1_thumb1_thu[2]](https://images0.cnblogs.com/blog/15172/201503/211054051419485.jpg "megadotnetmicromsg_thumb1_thumb1_thu[2]")
作者：
出处：
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-petter liu blog。
如对本文有疑问， 点击进行留言回复！！
我要评论
网友评论