• Redis是一个分布式缓存系统，支持多种数据结构，我们可以利用Redis轻松实现一个强大的秒杀系统。

  我们可以采用Redis 最简单的key-value数据结构，用一个原子类型的变量值(AtomicInteger)作为key，把用户id作为value，库存数量便是原子变量的最大值。对于每个用户的秒杀，我们使用 RPUSH key value插入秒杀请求， 当插入的秒杀请求数达到上限时，停止所有后续插入。

  然后我们可以在台启动多个工作线程，使用 LPOP key 读取秒杀成功者的用户id，然后再操作数据库做最终的下订单减库存操作。

  当然，上面Redis也可以替换成消息中间件如ActiveMQ、RabbitMQ等，也可以将缓存和消息中间件 组合起来，缓存系统负责接收记录用户请求，消息中间件负责将缓存中的请求同步到数据库
  原文：https://blog.csdn.net/suifeng3051/article/details/52607544 
  学习：秒杀系统架构分析与实战 > https://my.oschina.net/xianggao/blog/524943

• 比如说这个消息队列系统，我们来从以下几个角度来考虑一下。

  （1）首先这个mq得支持可伸缩性吧，就是需要的时候快速扩容，就可以增加吞吐量和容量，那怎么搞？设计个分布式的系统呗，参照一下kafka的设计理念，broker -> topic -> partition，每个partition放一个机器，就存一部分数据。如果现在资源不够了，简单啊，给topic增加partition，然后做数据迁移，增加机器，不就可以存放更多数据，提供更高的吞吐量了？

  （2）其次你得考虑一下这个mq的数据要不要落地磁盘吧？那肯定要了，落磁盘，才能保证别进程挂了数据就丢了。那落磁盘的时候怎么落啊？顺序写，这样就没有磁盘随机读写的寻址开销，磁盘顺序读写的性能是很高的，这就是kafka的思路。

  （3）其次你考虑一下你的mq的可用性啊？这个事儿，具体参考我们之前可用性那个环节讲解的kafka的高可用保障机制。多副本 -> leader & follower -> broker挂了重新选举leader即可对外服务。

  （4）能不能支持数据0丢失啊？可以的，参考我们之前说的那个kafka数据零丢失方案
  原文：https://blog.csdn.net/A_BlackMoon/article/details/85197979 
   

如果让你来负责一个电商双11大促系统，你会如何来考虑和设计？

• 大型促销活动带来的是流量暴涨，在高访问量的冲击下，电商系统会受到以下挑战：瞬间访问量可能是平时的几十倍；网络带宽被占满，用户响应很慢；机器负载高甚至宕机；数据库压力过大导致服务不可用,各家电商峰值系统的架构设计，由于电商规模、商业模式以及技术选型的不同，其技术方案多彩多样、百花齐放，着实令人兴奋，全面展现了互联网技术开放和创新的特征。下面从这些架构设计方案中，抽象和总结出其共性相通的核心思路，进行一些概述。核心思路集中表现为：采用分而治之的思想，大系统小做，小系统大做。浓缩一下就是三个字：快、稳、炫

• 快——天下武功，唯快不破

  快的目标是确保用户端快速流畅的体验。概括来说，可以通过以下技术手段实现快的目标。

  对前端页面的处理

  ·         将有效期较长的静态页面通过CDN（Content Delivery Network，内容分发网络）缓存到离用户最近的服务节点上。

  ·         将有效期较短或者需要对失效时间做最大限度控制的静态页面，通过类似于Memcache的高速缓存系统或类似于Squid的反向代理系统缓存在服务端。

  ·         将混合型页面（如商品单页）进行动静分离，静态数据（如商品介绍等）缓存在本地，动态数据（如可用库存和促销价格等）异步进行加载。

  对后端数据的处理

  ·         数据库SQL慢查询优化。例如，重构相关索引，对where子句进行优化等。

  ·         数据库读写分离。例如，MySQL的Master/Slave结构。

  ·         数据库分库分表。这是减轻单个数据库服务器压力的有效手段，不过同时也会带来系统的复杂性，是鱼和熊掌之间的关系。

  对网络传输的处理

  ·         执行负载均衡，第四层交换按实现分类，分为硬件实现和软件实现。通过硬件实现一般都由专业的硬件厂商作为商业解决方案提供，如F5等，这些产品非常昂贵，但能够提供非常优秀的性能和很灵活的管理能力。通过软件实现，如LVS等，虽然性能比专业硬件稍差，但软件实现配置起来更灵活。

  稳——不管风吹浪打，胜似闲庭信步

  稳的目标是确保系统端稳定可靠的服务。无论在任何情况下，都要做到尽可能不宕机、不出错。要做到这一点，可以在以下几个方面做文章。

  系统解耦

  拆分业务模块和功能模块，使得每个模块都做到高度内聚，然后用SOA，通过严格定义模块之间的服务接口，做到模块间的松散耦合。在一个模块发生问题时尽可能不影响其他模块的执行，尤其不能影响关键业务的执行。同时，可以对单个模块进行横向扩展，尤其是对关键的业务模块，以确保关键业务一定不能受影响。需要注意的是，模块划分的粒度应进行权衡，过细的粒度虽然可以带来更多的灵活性，但也会带来编程的复杂性。

  有损服务

  根据CAP（Consistency一致性，Availability可用性，Partition Tolerance分区容忍性）理论，三者不可得兼。对于电商平台，其中多数应用并不需要很强的一致性，因此合理的方式是用牺牲部分一致性来换取较高的可用性。有损服务（服务降级）就是一种提高系统稳定性和可用性的有效实践。在电商系统中，要优先保证类目浏览、产品单页和订单流程能够执行。

  数据库减负

  我们知道数据库是所有节点中最不容易扩展的，复杂的SQL查询条件会导致数据库负担过重，此时可用增加应用计算中间服务器的方式，通过高效简洁的SQL查询，应用计算中间服务器一次性地从数据库中取出最小全集的数据行，然后在内存中利用算法剔除冗余数据，以应用算法的复杂度换数据库负担的方式。

  炫——运筹于帷幄之中，决胜于千里之外

  炫的目标是确保业务端实时高效的调度。从日志收集和实时计算入手，通过对用户行为数据的可视化（图1），及时发现问题和洞察商机，调度应用系统，对用户多样化和个性化的需求进行智能引导。

• 原文：https://www.cnblogs.com/chunguang/p/5892274.html

   

  出现问题：

• 现有业务的冲击

  秒杀是营销活动中的一种，如果和其他营销活动应用部署在同一服务器上，肯定会对现有其他活动造成冲击，极端情况下可能导致整个电商系统服务宕机

  直接下订单

  下单页面是一个正常的 URL 地址，需要控制在秒杀开始前，不能下订单，只能浏览对应活动商品的信息。简单来说，需要 Disable 订单按钮

  页面流量突增

  秒杀活动开始前后，会有很多用户请求对应商品页面，会造成后台服务器的流量突增，同时对应的网络带宽增加，需要控制商品页面的流量不会对后台服务器、DB、Redis 等组件的造成过大的压力

  架构设计思想

  

   

  限流

  由于活动库存量一般都是很少，对应的只有少部分用户才能秒杀成功。所以我们需要限制大部分用户流量，只准少量用户流量进入后端服务器

  削峰

  秒杀开始的那一瞬间，会有大量用户冲击进来，所以在开始时候会有一个瞬间流量峰值。如何把瞬间的流量峰值变得更平缓，是能否成功设计好秒杀系统的关键因素。实现流量削峰填谷，一般的采用缓存和 MQ 中间件来解决

  异步

  秒杀其实可以当做高并发系统来处理，在这个时候，可以考虑从业务上做兼容，将同步的业务，设计成异步处理的任务，提高网站的整体可用性

  缓存

  秒杀系统的瓶颈主要体现在下订单、扣减库存流程中。在这些流程中主要用到 OLTP 的数据库，类似 MySQL、SQLServer、Oracle。由于数据库底层采用 B+ 树的储存结构，对应我们随机写入与读取的效率，相对较低。如果我们把部分业务逻辑迁移到内存的缓存或者 Redis 中，会极大的提高并发效率

  整体架构

  

•  

  原文：https://www.jianshu.com/p/62cce4ba2b8a