从1000万用户并发修改用户资料的假设场景开始
每次修改操作耗时200ms，每秒5个操作 MySQL连接数在5K，分10个库 5 *5k *10=25万TPS 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 出处：http://www.cnblogs.com/wintersun/ 本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。
