观后小结：技术演讲 - Real-life Riak at Mobile Interactiv...

摘要: Riak + Redis 构建 polyglot persistence；在同一物理硬件上跑 app server 和 db 要注意是否由于内存访问的竞争（NUMA）导致产生不必要的延迟。

这个技术演讲 - Real-life Riak at Mobile Interactive Group 是在 Skills Matter 站上看的

Mobile Interactive Group uses Riak extensively across many of their platforms including their SMS gateway and Facebook/iPhone voting platform. David Dawson gives the DeNormalised NOSQL Meetup a high level overview on how they have deployed Riak and some of the problems they faced (including the solutions).

分享了三点心得：

在他们的 wallet 实现中，单独使用 Riak 在一个 KV 中存放 balance 和 transaction history 时：随着使用量的增加，性能开始下降；由于 Riak 是 Eventual Consistency，分支状态有爆炸的风险，而且有超支的可能。改进方案是引入 Redis，balance 存 Redis，每个 transaction 存一个 Riak KV（Polyglot Persistence）。Riak 是 System of Truth，定期检查并保持 Riak 和 Redis 中的数据一致性。灾难恢复时基于 Riak 重建 Redis 中的 balance。

他们在生产环境中不定时出现 app server 到 Riak 的访问延迟，特别时负载上来的时候，延迟最长的时候能达到 60 秒。他们构建了一个测试环境来定位问题，磁盘换成 SSD 后确定不是 Disk I/O 导致的，用机器上的第二个网口单独构建一个 Riak 专用的 VLAN 后确定不是 Network I/O 导致的。由于他们之前是把 app server 和 Riak 同时运行在一个物理硬件上的，分离这两个角色后就没有延迟出现了。进一步的研究确定是原因是内存访问的竞争，使用 NUMACTL 对内存访问调优后做到在同一个物理硬件上同时运行 app server 和 Riak 相互也不打架。（关于 NUMA 概念的详细解释找到好文一枚）

基于 Riak 构建了一个可靠的 queue。

顺便吐槽：这个 Skills Matter 站的界面实在是够挫的，难道说是有意为之？



作者：czhang

原文链接：http://czhang.writings.io/articles/6-real-life-riak-at-mig-watched-20130519