参考当当网，京东，海尔等电商峰值策略，不考虑hadoop等高级框架，整理资料如下提供参考。
首先，设计和部署大流量、高并发系统的技术方案通常要面对以下几大难点。
1. 应用架构复杂，业务发展快，迭代速度快，各系统之间盘根错节，历史包袱重。不仅有牵一发而动全身的风险，更有边缘case出错影响主流程处理、耗尽过多资源的隐患。
2. 从前台到后台的业务流程长，用例多。在能承受的最大峰值上，存在短板效应。设计实现时要面面俱到。
3. 通常促销活动的持续时间短而集中，前期推广活动已经启动，在活动期间，短暂的系统不可用，也会带来惨重的销售损失与负面影响，没有亡羊补牢的机会。要确保系统的稳定性，平时的工作就要做足。
针对这些难点，有以下应对策略。
1. 基于SOA架构理念，降低系统耦合性，接口定义清晰明确，保证独立子系统的健壮性高，降低故障跨系统扩散风险，从而将伸缩性的困难逐步分解到各个系统。
2. 对系统进行分级，集中力量，突出重点系统。从卖场到交易流程均属于一级系统，这部分系统直接关乎用户体验和订单量。在系统稳定性和可靠性等指标上，设计标准高于后台系统。
3. 优先考虑用异步处理代替同步处理，做好系统异常的降级方案，保证有限的合格服务。
前端页面系统是电商业务的流量入口，需解决的核心问题是保证大流量高并发情况下的快速展示可用，这方面业界已有较为成熟的解决方案，如CDN、缓存、静态化、异步加载、与依赖的数据源解耦、同机部署、数据库读写分离等。通过这样的设计使前端无状态页面应用可以水平扩展，增加Web服务器即可提升系统能力。
商品的关键数据包括商品基本信息、库存和价格，库存和价格都依赖于商品基本信息，对于不同类型的数据，根据应用场景区别对待。平台化之后，每个商品都归属于一个商家，以商家ID为维度进行散列，将商品基本信息保存在数据库中，支持水平扩展，可以满足商品数据不断增长的需要。对于历史版本的商品信息，则迁移至历史版本库，作为订单交易快照供用户查询。库存数据在前端展示只关注是否有货，并不需要将每一次库存变化同步，在库存变为0或从0变为正整数时触发状态同步，交易下单时实时查询当前库存即可，此种变数量为状态的方式极大地减少了同步数据量，提高了数据一致性。
即便已经对不同类型的商品信息数据流进行了差异化处理，仍然不能排除短时间内会发生大量数据造成系统同步阻塞，影响正常业务运营操作的及时发布。极端情况下，超出系统处理能力还可能导致系统崩溃。为解决此类问题，采用批量、异步、分流、限流等手段进行处理。
批量、批次操作：
限制API调用频次的同时，提供批量API供商家对商品信息进行更新，批量更新方式减少了各环节交互次数，提高了系统吞吐量，更好地贴合营销活动中批量处理的需求。在系统内部，批量方式能够有效降低系统资源开销，并能对频繁更新的商品数据进行合并处理，提高处理速度，使数据更新及时准确。
增加异步处理，减少同步处理：
信息流同步经过多个系统，每个系统处理逻辑和吞吐能力不同，采用同步机制可能导致上游系统将下游系统拖垮，因此采用异步机制最为稳妥。异步方式有两点好处：一方面起到缓冲的作用，下游系统依据自身能力控制处理数据量，避免遭受超负荷的冲击，保证系统稳定运行；另一方面实现系统隔离解耦，一旦下游系统出现异常，上游系统仍然能正常处理数据，不至于引发连锁反应。
分流：
不同的信息对处理时效的要求也不同，库存、价格、商品上下架状态同步及时性要求很高，而商品基本信息，如名称、副标题、详情则相对较低。拆分不同的同步路径，对及时性要求高的数据配置更多的系统资源，既保障了敏感数据的及时性，又避免了数据积压相互干扰。同理，针对三种不同的数据来源渠道（ERP、数字业务系统、开放平台），也可通过分流方式保证自营实物、电子书和商家商品信息的及时同步。
限流：
多数的商品数据来源于商家，商家会通过一些第三方系统与开放平台对接，调用API进行数据同步。一些不合理的同步机制设置会频繁发起大量的数据同步请求，而多数请求属于无效数据，这类数据难以识别，会浪费大量的系统资源，干扰有效数据的处理。在开放平台对每个商家调用API的频次进行限制，根据商家商品数量合理分配，有效地抑制了无效数据的泛滥。
分布式：
分布式的交易系统是电商的未来。分布式系统解决两大难题：提高用户体验和增强容错能力。由于分布式系统设计时就会留有相当的流量增长空间，所以当一处数据中心饱和时，可以将其余的流量切入其他相对宽松的数据中心去，从而达到互为备份、互相支持的目的。与此同时，由于为提供用户就近服务，所以减少了网络延时，页面反应速度加快了。
逻辑优化、算法优化和代码优化：
1.优化算法，选择合适高效的算法，降低不必要的递归、循环、多层循环嵌套等计算。用简单的算法完成大部分情况，不要为少数特例而将算法复杂化。特例由特殊的分支处理。
2.避免申请过多不必要的内存开销。
3.及时释放资源，降低资源占用时间，包括内存、I/O、网络和数据库等。
4.善用缓存：缓存常用的、不易变化的；偶有变化，可以考虑缓存依赖机制。
5.慎用数据库锁。
6.恰当地使用事务，事务要细粒度。
7.选择适当的通信方式：Socket、Remoting、Web Services（REST和SOAP）、WCF、 Named Pipes等，要特别注意长连接和短连接的恰当使用。
8.计算并行化。
9.降低系统或模块之间的通信次数，例如工作流服务和数据库服务。
10.降低系统或模块之间的传输数据量，不必要传输的不传或少传。
11.异步计算，降低等待时间。
12.考虑延迟加载和提前加载两种方式。
13.分离原则：分离业务模块，如分离大I/O模块、分离高耗内存模块和分离高耗宽带模块。
14.统筹使用计算资源，如寻求内存计算、数据库计算和网络开销三者之间的最佳平衡。
最后，为了保障系统性能和伸缩性，不少时候需要牺牲或者完全拒绝某些功能，或者降低系统的灵活性和扩展性等。
在数据库层允许复杂的产品存储结构设计，以细粒度、深度优化的关系模型充分实现产品数据模型的通用性、可扩展性。在数据模型设计时完全不用关心客户端检索查找的复杂性和性能问题。
产品查询引擎将复杂的数据存储模型封装成一个简单的逻辑模型。这个逻辑模型实现的效果，完全等同于产品的所有属性都存储在同一张数据库表中，逻辑模型的每 个属性对应数据库表中的一个字段。在这个逻辑模型的基础上实现了一个简洁的DSL，供客户端进行检索查询。客户端工作在逻辑模型和DSL之上，检索查询简单、灵活，同样完全不用关心产品数据存储模型的复杂性和性能问题。
产品服务分不同集群进行部署，面向Web应用和其他服务的集群在运行期间几乎不会产生数据库请求，因此不管网站访问量和交易量多高，数据库都不会产生压力瓶颈。只需为Web和服务添加服务器，实现了高伸缩目标。
