秒杀系统的架构设计。
那么，何为秒杀系统呢?就是典型的、短时间的、大量的、突发访问，我们对于这类问题呢，总结有以下三种优化性能的思路：
异步处理，而不是同步处理 。
写入内存，而不是写入硬盘 。
分布式处理。
——那么，这三种优化秒杀系统性能的思路，不论秒杀时负载多大，都能够轻松的应对。redis能够满足以上三种优化性能，用redis能轻松实现秒杀系统。
为什么以上三种性能优化思路，能够轻松的解决秒杀系统的性能问题呢?下面我们一一的介绍。
异步处理，而不是同步处理。
秒杀这样的短时大并发的系统，在性能负载上面有一个很明显的波峰和长期波谷。是为了应对相当短时间内的大并发而准备大量服务器来应对，在经济上是非常不划算的。
因此呢，对付秒杀类的需求，我们就应该化同步为异步，用户请求写入内存后立刻返回。后台启动多个线程从内存池中异步读取数据，对其进行处理。
如果用户请求可能是1秒钟内进入的，系统实际处理完成可能花三十分钟。那么一台服务器在异步情况下其处理能力大于同步情况下1800多倍之多。
——异步处理，通常用MQ(消息队列)来实现。redis可以看作是一个高性能的MQ。因为它的数据读写都发生在内存之中。
写入内存，而不是写入硬盘。
对于传统的硬盘读写性能是相当差的，SSD硬盘比传统硬盘快100倍，而内存又比SSD硬盘快10倍以上。因此，写入内存，而不是写入硬盘，就能使系统的能力提升上千倍。也就是说，原来你的秒杀系统可能需要900台服务器支撑，现在一台服务器就可以扛得住了。
有些开发者就会有疑问了?写入内存，而不是持久化，如果此时计算机突然宕机了呢，写入的数据不就全部丢失了吗??如果你运气不好，倒霉呢?碰到服务器宕机，那你就没秒到了，有什么大不了呀!
——后面真正处理秒杀订单时，我们会把信息持久化到硬盘中。因此不会丢失关键的数据。redis是一个缓存系统，数据写入内存后就返回给客户端，能够支持这个特性。
分布式处理
要是你的客户很多，秒杀系统即使用了以上两种方案，还是捉襟见肘撑不住?不要紧的，还有下面这个大招[分布式处理]。如果一台服务器撑不住秒杀系统，那么就多用几台服务器。五台不行，就上一百台嘛。
——分布式处理，就是把海量用户的请求分散到多个服务器上，一般使用hash实现均匀分布。
这类系统在大数据云计算时代的今天已经有很多了。无非是用Paxos算法和Hash Ring实现的，redis Cluster正是这样一个分布式的产品。
使用Redis实现描述系统
redis和redis cluster(分布式版本)，是一个分布式缓存系统。其支持多种数据结构，也支持MQ。redis在性能上做了大量优化。因此使用Redis或者redis cluster就可以轻松实现一个强大的秒杀系统。
基本上，你用redis的这些命令就可以了。
RPUSH key value，插入秒杀请求。
——当插入的秒杀请求数达到上限时，停止所有后续插入。
LPOP key，后台启动多个工作线程。
读取秒杀成功者的用户id，进行后续处理，或者使用LRANGE key start end命令读取秒杀成功者的用户id，进行后续处理。
——每完成一条秒杀记录的处理，就执行INCR key_num。一旦所有库存处理完毕，就结束该商品的本次秒杀，关闭工作线程，也不再接收秒杀请求。
