文档介绍：-
. z
构建高并发高可用的电商平台架构实践
一、设计理念
1)多级缓存，静态化
客户端页面缓存-
. z
对于共享资源的，为了防止冲突，需要进展并发的控制，同时有些交易需要有事务性来保证交易的一致性，所以在交易系统的设计时，需考虑原子操作和并发控制。
保证并发控制一些常用高性能手段有，乐观锁、Latch、mute*、写时复制、CAS等；多版本的并发控制MVCC通常是保证一致性的重要手段，这个在数据库的设计中经常会用到。
3)基于逻辑的不同，采取不一样的策略
平台中业务逻辑存在不同的类型，有计算复杂型的，有消耗IO型的，同时就同一种类型而言，不同的业务逻辑消耗的资源数量也是不一样的，这就需要针对不同的逻辑采取不同的策略。
针对IO型的，可以采取基于事件驱动的异步非阻塞的方式，单线程方式可以减少线程的切换引起的开销，或者在多线程的情况下采取自旋spin的方式，减少对线程的切换(比方oracle latch设计)；对于计算型的，充分利用多线程进展操作。
同一类型的调用方式，不同的业务进展适宜的资源分配，设置不同的计算节点数量或者线程数量，对业务进展分流，优先执行优先级别高的业务。
4)容错隔离
系统的有些业务模块在出现错误时，为了减少并发下对正常请求的处理的影响，有时候需要考虑对这些异常状态的请求进展单独渠道的处理，甚至暂时自动制止这些异常的业务模块。
有些请求的失败可能是偶然的暂时的失败(比方网络不稳定)，需要进展请求重试的考虑。
5)资源释放
系统的资源是有限的，在使用资源时，一定要在最后释放资源，无论是请求走的是正常路径还是异常的路径，以便于资源的及时回收，供其他请求使用。
在设计通信的架构时，往往需要考虑超时的控制。
二、静态架构蓝图
整个架构是分层的分布式的架构，纵向包括CDN，负载均衡/反向代理，web应用，业务层，根底效劳层，数据存储层。水平方向包括对整个平台的配置管理部署和监控。
-
. z
三、剖析架构
1. CDN
CDN系统能够实时地根据网络流量和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的效劳节点上。其目的是使用户可就近取得所需容，解决Internet网络拥挤的状况，提高用户的响应速度。
对于大规模电子商务平台一般需要建CDN做网络加速，大型平台如淘宝、京东都采用自建CDN，中小型的企业可以采用第三方CDN厂商合作，如蓝汛、网宿、快网等。
当然在选择CDN厂商时，需要考虑经营时间长短，是否有可扩大的带宽资源、灵活的流量和带宽选择、稳定的节点、性价比。
2. 负载均衡、反向代理
一个大型的平台包括很多个业务域，不同的业务域有不同的集群，可以用DNS做域名解析的分发或轮询，DNS方式实现简单，但是因存在cache而缺乏灵活性；一般基于商用的硬件F5、NetScaler或者开源的软负载lvs在4层做分发，当然会采用做冗余(比方lvs+keepalived)的考虑，采取主备方式。
4层分发到业务集群上后，会经过web效劳器如ngin*或者HAPro*y在7层做负载均衡或者反向代理分发到集群中的应用节点。
选择哪种负载，需要综合考虑各种因素〔是否满足高并发高性能，Session保持如何解决，负载均衡的算法如何，支持压缩，缓存的存消耗〕；下面基于几种常用的负载均衡软件做个介绍。
LVS，工作在4层，Linu*实现的高性能高并发、可伸缩性、可靠的的负载均衡器，支持多种转发方式(NAT、DR、IP Tunneling)，其中DR模式支持通过广域网进展负载均衡。支持双机热备(Keepalived或者Heartbeat)。对网络环境的依赖性比拟高。
Ngin*工作在7层，事件驱动的、异步非阻塞的架构、支持多进程的高并发的负载均衡器/反向***。可以针对域名、目录构造、正则规则针对做一些分流。通过端口检测到效劳器部的故障，比方根据效劳器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测。对于session sticky，可以基于
-
. z
ip hash的算法来实现，通过基于cook