图墙后端
图墙即商品列表，分为搜索、类目、推荐等多种形式。
1、 背景：之前对所有请求都是在同一块逻辑里处理，可维护性与拓展性都很差；
行动与结果：通过重构将业务功能拆分到不同的 Task 中，在后台系统对接口
链路进行配置，实现接口动态化，对于大多数小需求都可以通过改配置实现，
大幅提高了对业务迭代的快速支持。
2、 背景：运营在做团购等活动时，希望能实时的获取活动中商品的表现；
行动与结果：在 Strom 中接入点击、加购消息，将数据统计暂存在 Redis 中，
每隔 1min 进行 top-k 排序，为运营对商品进行排序和推送提供了数据支持。
3、 背景：随着业务的发展，应用已经难以支撑大促时高 QPS 访问；
行动与结果：通过将请求同步转异步、GC 调优、Redis 缓存等手段将单机
QPS 从 200+提升到 400+。
Zonda 缓存系统
Zonda 是 KV 结构的数据缓存系统，通过在所有机器的磁盘上维护一份数据全量缓
存，以提供高效的查询效率。
1、 背景：Zonda 最初是基于内存存储的，这就限定了它不能接入量太大的数据；
行动与结果：研发了一套基于文件系统的单机 KV 数据库，通过 mmap、索
引、WAL 等机制保证高性能读写的同时支持大量数据存储。
2、 背景：一个数据会有多份副本，当数据发生变化时会有数据一致性的问题；
行动与结果：应用在收到增量消息时并不是马上更新数据，而是在 Zonda 上维
护一个最低水位，应用只能读取到这个最低水位以下的数据。
51 虚拟卡项目
与银行合作，用户可以在 51 上办理银行二类户、余额充值提现、购买理财产品。
1、 背景：余额充值、提现需要调用银行接口，而银行接口通常处理时间很长，所以
不能同步的调用银行接口再返回结果给前端；
行动与结果：在充值时，通过事务消息保证订单入库及消息发送的一致性，然后
在异步消费消息的过程中调用银行接口及失败重试。
2、 背景：用户购买理财产品时需要保证理财产品购买、减券、减库存的一致性；
行动与结果：在下单时，先创建一个初始化的订单，同步的减券、减库存，如果
1
失败则通过消息异步的回券、回库存。