拼多多bug事件后对技术架构的思索

heyuantt

背景引用
最近拼多多的bug导致被羊毛党薅羊毛，外面传说造成的损失有的说1000万，有的说200亿，反正是因为业务过失导致公司损失惨重，后来想下拼多多的架构团队是否可以在业务异常数据监控这块的架构完善完善，当bug发生时，监控系统检测出大量异常数据监控报警立马通知到技术团队在第一时间进行代码、脚本回滚来止损，仔细想想，业务数据异常监控做好的话，完全可以止损与萌芽阶段！


此时再引用一个百万用户同时访问热点缓存的架构优化方案，在此基础上进行完善
首先业务架构是分布式集群 + redis cluster集群，热点数据一下子进来后会导致所有的请求一下子爆喷式地奔向一台机器，Redis高性能机器一般10万每秒的请求，处理不过来，机器瞬间宕机（这种情况大型互联网公司很常见，比如前段时间鹿晗宣布恋爱的事情，用户疯狂的访问量直接导致故障），请求转发到下一台机器，下一台机器也是同样的命运，最终导致整个缓存集群雪崩，如下图

   所以，此时完全可以基于大数据领域的流式计算技术来进行实时数据访问次数的统计，比如storm，spark等。这里的一个解决方案就是实时数据访问次数统计中比如发现一秒之内，某条数据突然访问次数超过1000条，直接对这条数据判定为热点数据，将热点数据写入zookeeper中。最后自己的因为系统可以对zookeeper指定的热点缓存对应的znode进行监听，有变化立马感知，此时业务系统层面可以立马将缓存数据从数据库加载到本地缓存，ehcache，hashmap都可以，因为业务系统缓存的热点数据也是很少的，不会占用太大的空间，完全可以。再后用户的热点数据访问直接在业务系统中就给挡回去，落不到缓存集群中

   类似拼多多或者之前腾讯视频会员的业务数据异常监控处理方案，也可以基于大数据领域的流式计算技术来进行异常数据的监控，当然是否为异常数据要进行人为事先进行业务的梳理以及可能性异常数据发生的事情枚举。比如拼多多这次事件是优惠券流向了虚拟物品（话费、Q币）就是以0或者很低的钱payment→0购买了100元的话费。可以这样定义一种用户异常行为规则，售卖商品的类型为不用发货的虚拟商品，同时商品价值/付款金额的值很大，或者除不尽抛异常，此种行为定义为用户异常行为，当异常行为到达一个阈值的时候报警通知技术团队。其实前段时间的腾讯视频会员也是这种情况，用户以2毛钱买一年的会员，有的人买了100年，但是腾讯是自家的会员没多大损失，拼多多就不一样了，要跟运营商进行结算，这损失的是实实在在的人民币