利用Redis设计库存系统的苦与乐
在秒杀等高并发场景下，既要保证库存安全，也要拥有极高的系统性能。从存储结构上，很多同学会选用Redis，毕竟Redis的单线程操作特性，很好地避免了线程安全的问题，同时具备极高的读写性能。
我们先来看下库存系统设计的几大核心要点：
1. 库存安全：既要保证线程安全，也要防止出现超卖
2. 同步响应：业务场景基本不允许异步响应库存扣减结果
3. 性能极限：在seckill场景下，性能总是被要求越高越好
我们来看下如何利用Redis来解决上面的三个问题。
一.库存安全
利用Redis来做库存扣减，避免超限的"方法"很多，坑也很多，我们先来看下常用的陷阱有哪些。
1. 先获取当前库存值进行比较，再进行扣减
defdecr_stock():conn=redis_conn()key="productA"current_storage=conn.get(key)current_storage_int=int(current_storage)ifcurrent_storage_int<=0 :return0result=conn.decr(key)returnresult
我们先在Redis中拿到当前的库存值，然后check是否已经扣减到了零，如果已经扣减到了零，则直接return；否则，就利用Redis的decr原子操作进行扣减，同时返回扣减后的库存值。
这种方法的问题很明显，在并发条件下，会出现脏读，设想一个场景，AB两个请求进来，A获取的库存值为1，B获取的库存值为1，然后两个请求都被发到redis中进行扣减操作，然后这种场景下，A最后得到的库存值为0；但是B最后得到的库存值为-1，超限。
2. 先扣减库存，再做比较，跟进情况是否做回滚
defdecr_stock():conn=redis_conn()key="productA"current=conn.decr(key)ifcurrent>=0:returncurrentelse: #回滚库存conn.incr(key)return0
直接先对库存值进行扣减，得到当前的库存值；然后，对此库存值进行check，如果库存>=0，则返回库存值，如果库存<0，则回滚库存，以便于防止负库存量的存在。
Redis Decr命令：DECR 命令会返回键 key 在执行减1操作之后的值。
这种做法引入了两个新的问题：
1).如果大批量的并发请求过来，redis承受的写操作的量，是加倍的，因为回滚库存的存在导致的。所以这种情况下，高并发量进来，极有可能将redis的写操作打出极限值，然后会出现很多redis写失败的错误警告
2). Redis的Decr操作和回滚操作无法保证原子性，在宕机情况下，容易产生数据不一致
3.先扣库存，然后通过整数溢出控制，根据情况进行回滚
defdecr_stock():conn=redis_conn()key="productA"current=conn.decr(key) #通过整数控制溢出的做法ifcheck_overflow(current):returncurrentelse: #回滚库存conn.incr(key)return0 defcheck_overflow(stock): #如果当前库存未被递减到0，则check_number为int类型，isinstance方法检测结果为true #如果当前库存已被递减到负数，则check_number为long类型，isinstance方法检测结果为falsecheck_number=sys.maxint - stockcheck_result=isinstance(check_number,int)returncheck_result
这种做法和方法2类似，只是比对部分由直接和0比对，变成了通过检测integer是否溢出的方式来进行。这样就彻底解决了高并发情况下，直接和零比对，限制不住的问题了。
虽然此种做法，相对于做法二说来，要靠谱很多，但是仍然解决不了在高并发情况下，redis写并发量加倍的问题，极有可能某个促销活动，在开始的那一刻，直接将redis的写操作打出问题来。
4.基于分布式锁的库存扣减
defdecr_stock():key ="productA" lock = getLock(key)iflocked ==1: current_storage = conn.get(key) current_storage_int = int(current_storage)ifcurrent_storage_int<=0:return0 result = conn.decr(key)returnresultelse:return"someone in it"
Redis在2.8以后支持Lua脚本的原子性操作，可以用来做分布式锁，解决超限的问题。
5. All in Lua
defstorage_scenario_six(): conn = redis_conn()lua =""" local storage = redis.call('get','storage_seckill') if storage ~= false then if tonumber(storage) >0 then return redis.call('decr','storage_seckill') else return 'storage is zero now, can't perform decr action' end else return redis.call('set','storage_seckill',10) end """result = conn.eval(lua,0) print(result)
二、同步响应
如果只用Redis来进行存储，处理完数据直接返回前端即可。如果还要持久化到DB，要尽量避免直接操作DB，因为DB往往是最大的IO瓶颈，如果要异步落库到DB，比如使用MQ。要注意处理Redis扣减和消息发送的原子性处理。
三、性能
官网上redis的读写性能能到10W/QPS左右，这个量级应该可以解决绝大部分的场景。
但是经常有同学在压测的时候达不到这个性能，主要还是卡在网络环境上，在5W/QPS的时候，带宽就超过10M/s了。所有想追求Redis的极致性能，最好还是在同机房进行调用。
该应用场景为DMP缓存存储需求，DMP需要管理非常多的第三方id数据，其中包括各媒体cookie与自身cookie（以下统称supperid）的mapping关系，还包括了supperid的人口标签、移动端id（主要是idfa和imei）的人口标签，以及一些黑名单id、ip等数据。
在hdfs的帮助下离线存储千亿记录并不困难，然而DMP还需要提供毫秒级的实时查询。由于cookie这种id本身具有不稳定性，所以很多的真实用户的浏览行为会导致大量的新cookie生成，只有及时同步mapping的数据才能命中DMP的人口标签，无法通过预热来获取较高的命中，这就跟缓存存储带来了极大的挑战。
经过实际测试，对于上述数据，常规存储超过五十亿的kv记录就需要1T多的内存，如果需要做高可用多副本那带来的消耗是巨大的，另外kv的长短不齐也会带来很多内存碎片，这就需要超大规模的存储方案来解决上述问题。
人⼝标签主要是cookie、imei、idfa以及其对应的gender（性别）、age（年龄段）、geo（地域）等；mapping关系主要是媒体cookie对supperid的映射。以下是数据存储⽰示例：
媒体编号-媒体cookie=>supperid
supperid =>{ age=>年龄段编码，gender=>性别编码，geo=>地理位置编码 }
imei or idfa =>{ age=>年龄段编码，gender=>性别编码，geo=>地理位置编码 }
显然PC数据需要存储两种key=>value还有key=>hashmap，⽽而Device数据需要存储⼀一种
key=>hashmap即可。
存储吃紧的一个重要原因在于每天会有很多新数据入库，所以及时清理数据尤为重要。主要方法就是发现和保留热数据淘汰冷数据。
网民的量级远远达不到几十亿的规模，id有一定的生命周期，会不断的变化。所以很大程度上我们存储的id实际上是无效的。而查询其实前端的逻辑就是广告曝光，跟人的行为有关，所以一个id在某个时间窗口的（可能是一个campaign，半个月、几个月）访问行为上会有一定的重复性。
数据初始化之前，我们先利用hbase将日志的id聚合去重，划定TTL的范围，一般是35天，这样可以砍掉近35天未出现的id。另外在Redis中设置过期时间是35天，当有访问并命中时，对key进行续命，延长过期时间，未在35天出现的自然淘汰。这样可以针对稳定cookie或id有效，实际证明，续命的方法对idfa和imei比较实用，长期积累可达到非常理想的命中。
Hash表空间大小和Key的个数决定了冲突率（或者用负载因子衡量），再合理的范围内，key越多自然hash表空间越大，消耗的内存自然也会很大。再加上大量指针本身是长整型，所以内存存储的膨胀十分可观。先来谈谈如何把key的个数减少。
大家先来了解一种存储结构。我们期望将key1=>value1存储在redis中，那么可以按照如下过程去存储。先用固定长度的随机散列md5(key)值作为redis的key，我们称之为BucketId，而将key1=>value1存储在hashmap结构中，这样在查询的时候就可以让client按照上面的过程计算出散列，从而查询到value1。
过程变化简单描述为：get(key1) ->hget(md5(key1), key1) 从而得到value1。
如果我们通过预先计算，让很多key可以在BucketId空间里碰撞，那么可以认为一个BucketId下面挂了多个key。比如平均每个BucketId下面挂10个key，那么理论上我们将会减少超过90%的redis key的个数。
具体实现起来有一些麻烦，而且用这个方法之前你要想好容量规模。我们通常使用的md5是32位的hexString（16进制字符），它的空间是128bit，这个量级太大了，我们需要存储的是百亿级，大约是33bit，所以我们需要有一种机制计算出合适位数的散列，而且为了节约内存，我们需要利用全部字符类型（ASCII码在0~127之间）来填充，而不用HexString，这样Key的长度可以缩短到一半。
下面是具体的实现方式
参数bit决定了最终BucketId空间的大小，空间大小集合是2的整数幂次的离散值。这里解释一下为何一个字节中只有7位可用，是因为redis存储key时需要是ASCII（0~127），而不是byte array。如果规划百亿级存储，计划每个桶分担10个kv，那么我们只需2^30=1073741824的桶个数即可，也就是最终key的个数。
碎片主要原因在于内存无法对齐、过期删除后，内存无法重新分配。通过上文描述的方式，我们可以将人口标签和mapping数据按照上面的方式去存储，这样的好处就是redis key是等长的。另外对于hashmap中的key我们也做了相关优化，截取cookie或者deviceid的后六位作为key，这样也可以保证内存对齐，理论上会有冲突的可能性，但在同一个桶内后缀相同的概率极低(试想id几乎是随机的字符串，随意10个由较长字符组成的id后缀相同的概率*桶样本数=发生冲突的期望值<<0.05,也就是说出现一个冲突样本则是极小概率事件，而且这个概率可以通过调整后缀保留长度控制期望值)。而value只存储age、gender、geo的编码，用三个字节去存储。
另外提一下，减少碎片还有个很low但是有效的方法，将slave重启，然后强制的failover切换主从，这样相当于给master整理的内存的碎片。
推荐Google-tcmalloc， facebook-jemalloc内存分配，可以在value不大时减少内存碎片和内存消耗。有人测过大value情况下反而libc更节约。
1）kv存储的量级必须事先规划好，浮动的范围大概在桶个数的十到十五倍，比如我就想存储百亿左右的kv，那么最好选择30bit 31bit作为桶的个数。也就是说业务增长在一个合理的范围（10 15倍的增长）是没问题的，如果业务太多倍数的增长，会导致hashset增长过快导致查询时间增加，甚至触发zip-list阈值，导致内存急剧上升。
2）适合短小value，如果value太大或字段太多并不适合，因为这种方式必须要求把value一次性取出，比如人口标签是非常小的编码，甚至只需要3、4个bit（位）就能装下。
3）典型的时间换空间的做法，由于我们的业务场景并不是要求在极高的qps之下，一般每天亿到十亿级别的量，所以合理利用CPU租值，也是十分经济的。
4）由于使用了信息摘要降低了key的大小以及约定长度，所以无法从redis里面random出key。如果需要导出，必须在冷数据中导出。
5）expire需要自己实现，目前的算法很简单，由于只有在写操作时才会增加消耗，所以在写操作时按照一定的比例抽样，用HLEN命中判断是否超过15个entry，超过才将过期的key删除，TTL的时间戳存储在value的前32bit中。
6）桶的消耗统计是需要做的。需要定期清理过期的key，保证redis的查询不会变慢。
人口标签和mapping的数据100亿条记录。
优化前用2.3T，碎片率在2左右；优化后500g，而单个桶的平均消耗在4左右。碎片率在1.02左右。查询时这对于cpu的耗损微乎其微。
另外需要提一下的是，每个桶的消耗实际上并不是均匀的，而是符合多项式分布的。
上面的公式可以计算桶消耗的概率分布。公式是唬人用的，只是为了提醒大家不要想当然的认为桶消耗是完全均匀的，有可能有的桶会有上百个key。但事实并不没有那么夸张。试想一下投硬币，结果只有两种正反面。相当于只有两个桶，如果你投上无限多次，每一次相当于一次伯努利实验，那么两个桶必然会十分的均匀。概率分布就像上帝施的魔咒一样，当你面对大量的桶进行很多的广义的伯努利实验。桶的消耗分布就会趋于一种稳定的值。接下来我们就了解一下桶消耗分布具体什么情况：
通过采样统计
31bit（20多亿）的桶，平均4.18消耗
100亿节约了1.8T内存。相当于节约了原先的78%内存，而且桶消耗指标远没有达到预计的底线值15。
对于未出现的桶也是存在一定量的，如果过多会导致规划不准确，其实数量是符合二项分布的，对于2 30桶存储2 32kv，不存在的桶大概有（百万级别，影响不大）：
Math.pow((1 - 1.0 / Math.pow(2, 30)), Math.pow(2, 32)) * Math.pow(2, 30)
对于桶消耗不均衡的问题不必太担心，随着时间的推移，写入时会对HLEN超过15的桶进行削减，根据多项式分布的原理，当实验次数多到一定程度时，桶的分布就会趋于均匀（硬币投掷无数次，那么正反面出现次数应该是一致的），只不过我们通过expire策略削减了桶消耗，实际上对于每个桶已经经历了很多的实验发生。
总结：信息摘要在这种场景下不仅能节约key存储，对齐了内存，还能让Key按照多项式分布均匀的散列在更少量的key下面从而减少膨胀，另外无需在给key设置expire，也很大程度上节约了空间。
这也印证了时间换空间的基本理论，合理利用CPU租值也是需要考虑的。
关注分布式存储技术以及分布式计算方法
还记得刚工作那会，每每听到大牛们聊技术，各种专业术语，巴拉巴拉的，简直像是在听天书，比如什么中间件、分布式、SOA、无状态、热更新、懒加载、ACID、LVS、LDAP、VIP、CDN、负载均衡、鲁棒性、POJO、DSL、DI、IOC，太多太多了。一转眼快 10 年过去了，当很多新人再问到我这些名词的时候，我就在想，能不能用通俗易懂的大白话，就能聊明白这些专业的技术知识呢？
最近，给几个公司做技术咨询，经常会聊到秒杀系统。所以，借这次机会，尝试用大白话和大家聊聊 Redis 秒杀系统的设计与实现，。
说起 “秒杀”，我相信大家肯定都耳熟能详了，双十一零点抢购、手机整点抢购、抢火车票、1 元秒杀、抢红包等等，都可以说是秒杀的各种应用场景了。
秒杀系统的设计 ，难就难在，在极短的时间内，应对瞬时涌入平时成百上千倍的巨大流量，还包括各种攻击刷量作弊等未知流量，最终我们要保证在用户体验顺畅良好的情况下，不能多卖或者少卖。
而当我们公司决定要做秒杀系统的时候，我就去找业务，到时大概会有多少 UV，不知道 10 倍或者 100 倍？然后去找老板，给技术多少预算，最多平时的 10 倍不能再多了，当然越少越好，呵呵，也就是说让我们用平时最多 10 倍的预算去解决不可预估的用户流量，怎么做？要是有钱直接扔 1 万台服务器跑去吧，钱能解决的事就不是事，但问题是现在还没那么多钱，还要把事情搞定。
在聊秒杀系统设计之前，让我们先回到现实生活中，聊聊常见的“秒杀”场景和秒杀场景的独有特点，以及它们都是怎么应对的，在应对过程中都需要注意什么。
日常生活中，其实也有很多秒杀场景，比如，早上 9 点超市开门，老大爷老大妈抢购蔬菜水果，是不是？ 还有，新楼盘开盘抢购，是不是？ 股市开盘、交易所现场，是不是？
对的，生活中其实有太多类似场景了， 你有没有发现“秒杀”的独有特点呢？
记住了上面三个特点，我们就可以区分和确定秒杀的业务场景了。 这里我举一个特别的例子， 你说挤公交车，算不算秒杀场景呢？
下面，我再和大家聊一个关于抢猪肉的故事。
在保安部门充分讨论之后，保安大队长决定通过以下安排，在保证人员安全的前提下，还要做到相对公平。
后来，活动井然有序的开始了，但是由于猪肉销售场地太远，销售窗口又少，老大爷和老大妈们买肉又精挑细选，导致整个过程很漫长，而且外面等候的人们都开始骚动起来，这个时候保安大队长赶紧找到经理：
故事讲完了，如果我们把上面的故事，理解为秒杀业务场景，我们就可以总结出一个 秒杀系统的设计原则 了：
每个经典的系统服务组件，我们总是能发现其赖以高性能的机制。
所以我们这次也是一样，借着Redis的专题，用实例来写点对 Reactor模式 的理解。
首先我们免不了俗，简单介绍下Reactor的相关概念：
Reactor模式的角色构成(Reactor模式一共有5中角色构成)：
TODO:等有时间了实现一个多Reactor线程池模式的Demo放上来。
