文档介绍：电商系统峰值架构研究
洋码头内部资料
梁中华
lzh@
目标场景
类似双10,双11,黑五这类大促
请求量、网络流量,短时间可达平时10倍,甚至几十倍
秒杀,限时抢购
瞬时流量可达平时的几十、上百倍,一个不慎,可能瞬间把整个集群摧垮
各种没有节操的攻击
找你的薄弱环节,狠狠地压你
各种网站联盟、线上、线下引流
面临的问题
带宽可能不够:做好图片、页面、资源压缩,节省流量
数据库可能撑不住:IO、CPU、连接数过高
缓存服务器可能撑不住:CPU,连接数过高
Session服务器负载过高
应用服务器可能撑不住:
CPU、连接数、线程数、执行时间过长
第三方接口可能会撑不住:
短信、个推等
个别页面或业务的瞬间压力过大可能会导致整个系统面临很大的风险
各种原因,可能会宕机
整体解决思路
提前进行容量规划和场景分析
场景分析很重要、分析出可能的热点和薄弱环节
功夫在戏外,平时工作要做足
核心思想:
分而治之,大系统小做、小系统大做
Partition(Scalable) Everything, Async Everywhere, Caching Everything, Remember Everything Will Fail(Cluster,Monitor)
两个重点方向:
既要“快”–天下武功,唯快不破
又要“稳”–稳定压倒一切
“快”—Caching Everything
将有效期较长的页面进行CDN缓存或反向***缓存
有效期短的页面或数据缓存到本地内存或者分布式缓存服务器,如Redis
考虑缓存失效情况,避免缓存失效穿透,造成后端瞬间压力过大
将混合型页面进行动静分离,如单品页,介绍性内容静态化;价格、库存等动态异步加载
有些只是Request级别或线程级别的数据,可以缓存在HttpContext或ThreadStatic变量中,避免多次从远程获取
“快”—应用代码结构和流程
尽量避免使用Session
尽量避免大量的嵌套循环、无意识的linq join操作,大数据量的排序和筛选,选取高效的算法。
尽量避免大数据量的复杂字符串操作
尽量减少远程调用的次数,提供粗粒度接口
远程调用时尽量使用长连接,减少频繁创建连接带来的资源损耗
尽量避免需要大量序列化和反序列化的操作
尽量避免创建大快内存,减少GC压力
必要时进行异步处理和并行处理
“快”—数据库
SQL优化: 重构索引、where字句优化
减少大事务、最小化一致性要求
数据库读写分离:Master-Slaver
数据库分库:按业务垂直拆分,分散压力,保护主流程
数据库分区:按时间进行分区
通过MQ异步写库:削峰填谷
“快”—负载均衡
通过负载均衡进行快速扩展集群容量
实现弹性扩容,Scalable Everything!
通过硬件实现:F5, NetScaler
通过软件实现:LVS, HAProxy,Nginx
RPC服务框架自动实现负载均衡,如dubbo
自实现各种负载均衡算法
稳-分而治之
按业务,按模块进行拆分,使每个模块又轻又快,小而美。
公共模块SOA化,集中监控和扩容
使CPU密集、IO密集、占用内存高等不同资源敏感的服务得以不同的方式进行扩容
热点分离,减少各模块之间互相影响,保护核心业务流程
可以针对性的进行监控、流量控制和扩容
做好超时控制,每个远程调用都设置合理的超时时间
参考架构—当当