这部分专门讲述IM消息存储的设计。消息存储的难度在于，要考虑以下的场景： 离线消息存储。即发送消息时对方不在线该怎么处理。 单聊、群聊消息。 随着

IM做为非常经典的服务器系统，其设计时候的考量具备代表性，所以这一次花几个篇幅讨论其相关设计。 主要内容相当部分参考了 一套海量在线用户的移动端

概述 OpenResty（以下简称OR）是Lua应用的典范，其最大的亮点在于，使用Lua协程搭配上异步非阻塞的IO，这样开发者可以使用同步方式

redis中为了实现高可用（High Availability，简称HA），采用了如下两个方式： 主从复制数据。 采用哨兵监控数据节点的运行情况，

一致性保证 最终一致性（eventual consistency）：如果停止更新数据，等待一段时间（时间长度未知），则最终所有读请求将返回相同的

本章描述分布式系统中可能出现的各种问题。 故障与部分失效 单机上的程序，以一种确定性的方式运行：要么工作，要么出错。 然而涉及到多台节点时，会出现

注：本文为重新发布2017-06-17所写博客，以下为正文部分。 上周我们的存储服务在某个线上项目频繁出现崩溃，花了几天的时间来查找解决该问题

事务提供了一种机制，应用程序可以把一组读和写操作放在一个逻辑单元里，所有在一个事务的读和写操作会被视为一个操作：要么全部失败，要么全部成功，

键值数据的分区 基于关键字区间的分区 给每个分区分配一段连续的关键字或者关键字区间（以最小值和最大值来指示），从关键字区间的上下限可以确定哪个分

主从复制 集群中有一个主节点，写操作都必须经过主节点完成，读操作主从节点都可以处理。 同步复制和异步复制 同步复制 数据在副本上落盘才返回。 优点：保