蘑菇街的101天 — 团购重构

PS:很长时间没有写博了.主要原因就是最近一个人在支撑蘑菇街的团购业务,分身乏术.虽然没有写出分享,但还是有个人的笔记.

相对而言,博客的价值在于分享,但是由于很多的时侯,分享依赖的业务场景不同,所以很多的时侯并不适用,亦或者现场恢复困难,写出来的东西没有具体的实例,感觉不太稳妥.

最简单的一个就是关于innoDB索引计算的一个case.排查过程不说了,直接上结果,就是mysql在进行索引消耗计算的时侯存在一定的误差,可能会使用不恰当的索引.所以,在sql的书写中,尽量使用force index 语句,来告诉Mysql,使用某一条索引进行查寻.当然,如过数据量不大,十万级别的数据,看不出效果(线上场景8000万数据).

其次的一点收获就是网站开发的.由于我负责了整个团购业务,所以有很多事情必需考虑:

• cache 一致性
• cache 被击穿
• 业务架构
• DB设计
• …

先说下cache一致性.前提说一下,蘑菇街使用了kohana框架,是个MVC的,所以对于底层的Model,是需要有一个缓存的,这个缓存是数
据缓存,因为别人也会调用这个接口所以,这边是一个具体的商品缓存,另外一个就是在业务上,因为展现的每一个商品都是需要拼接数据的,所以这边也会有个缓
存,业务方的缓存,然后就是整个页面的缓存,这边就是运维的事了.是不是就完了?没有,因为点击人数这个坑,刷新点击人数这个操作不能实时刷数据库,所以
也会有个缓存,每隔10刷入数据库,所以,在蘑菇街团购上,看到的参与人数一定会是10的倍数.这和天猫的那个*3不
可一概而论.回到主题,最好的作法,这个缓存也是需要实时显示,目前已经在处理这个.也就是说,我们码农所见的缓存就是三个,数据缓存,业务缓存,热点缓
存.然后问题就来了,缓存必定带有延迟,不能保证实时,同时,多层缓存对问题的定位带来了挑战.所以这边具体说下我的一个解决的丝路,第一个就是承认不一
致,但是要让不一致的时间尽可能短.对于数据层缓存,是可以保证其实时性,因为在代码里加上修改更新缓存即可,而对於业务层,数据层所做的极为有限,所以
只能人为的缩短缓存时间,目前是30s,也就是,平均期望15s的时间,数据会达到最新,然后,对外提供实时点击数量查寻接口,在对外接口中使用获取实时
点击数的接口.

再说说缓存被击穿,这个很容易理解,缓存的用途就是防止接触数据库,但实际上,如过缓存获取失败,我们通常会再访问一遍数据库,这个时侯问题就来
了.如恶意攻击者一直访问一个没有的商品,那么每次都会访问到数据库,加上DDOS,数据库多半就趴了.所以这边作的第一点就是未获得数据也写缓存,缓存
value为空.这也有一个问题,就是恶意刷很多id,导致也读写库,所以还得加上数据验证.我们有自增id,以他进行数据校验,大于最大的,不读库直接
返回失败.这也有一个问题,如何获得最大id,这边的方法是存缓存,这就存在一个脏读问题,不过,可以接受.

业务架构,也是个麻烦事,之前的报名逻辑是先选商品,然后报名活动.这个逻辑很好,很通顺,但是,如果不同的活动要求不同的商品,这就比较麻烦了.
也可以选了商品再看可报名活动但是交互太差,所以这边改成了先选活动,再选商品.这是一个取舍的过程.了解整个业务,选择正确的逻辑.

然后是DB设计,标准热点库,不多说了.

以前以为,专心做技术,现在想法在一点一点改变,技术万变不离其宗,业务,千奇百怪.做得好技术不代表干得了业务.业务更多的是强调抽象分层,而技术更多的是研究.未来的道路还有很长,gogogo