蘑菇街的101天 — 团购重构

PS:很长时间没有写博了.主要原因就是最近一个人在支撑蘑菇街的团购业务,分身乏术.虽然没有写出分享,但还是有个人的笔记. 相对而言,博客的价值在于分享,但是由于很多的时侯,分享依赖的业务场景不同,所以很多的时侯并不适用,亦或者现场恢复困难,写出来的东西没有具体的实例,感觉不太稳妥. 最简单的一个就是关于innoDB索引计算的一个case.排查过程不说了,直接上结果,就是mysql在进行索引消耗计算的时侯存在一定的误差,可能会使用不恰当的索引.所以,在sql的书写中,尽量使用force index 语句,来告诉Mysql,使用某一条索引进行查寻.当然,如过数据量不大,十万级别的数据,看不出效果(线上场景8000万数据). 其次的一点收获就是网站开发的.由于我负责了整个团购业务,所以有很多事情必需考虑: cache 一致性 cache 被击穿 业务架构 DB设计 … 先说下cache一致性.前提说一下,蘑菇街使用了kohana框架,是个MVC的,所以对于底层的Model,是需要有一个缓存的,这个缓存是数 据缓存,因为别人也会调用这个接口所以,这边是一个具体的商品缓存,另外一个就是在业务上,因为展现的每一个商品都是需要拼接数据的,所以这边也会有个缓 存,业务方的缓存,然后就是整个页面的缓存,这边就是运维的事了.是不是就完了?没有,因为点击人数这个坑,刷新点击人数这个操作不能实时刷数据库,所以 也会有个缓存,每隔10刷入数据库,所以,在蘑菇街团购上,看到的参与人数一定会是10的倍数.这和天猫的那个*3不 可一概而论.回到主题,最好的作法,这个缓存也是需要实时显示,目前已经在处理这个.也就是说,我们码农所见的缓存就是三个,数据缓存,业务缓存,热点缓 存.然后问题就来了,缓存必定带有延迟,不能保证实时,同时,多层缓存对问题的定位带来了挑战.所以这边具体说下我的一个解决的丝路,第一个就是承认不一 致,但是要让不一致的时间尽可能短.对于数据层缓存,是可以保证其实时性,因为在代码里加上修改更新缓存即可,而对於业务层,数据层所做的极为有限,所以…