让内存中的NoSQL数据存储适合企业级应用

1. 可用性

无论你做什么，对于你的应用来说数据必须是时刻可用的。这对于内存数据库尤为重要；因为，如果没有得当的措施，当下面的情形发生时你的数据将会部分或全部丢失：

1. 节点失败（在云（cloud）中经常发生）；
2. 进程重启（你可能需要不时的进行重启）；
3. 需要扩展（我们假设你可能需要这个）

对于情形1和情形2有两种方式来解决；情形3将在稍后讨论。

• 复制:你要确保将你的数据保存一份到集群的另一节点，如果是另一数据中心则更为可靠，以便应付数据中心发生故障（亚马逊AWS在2012年至少发生了4次故障）。不幸的是事情并非如此简单。随便就能举一个复制非常困难的例子：
  一旦程序写的频率增加，你会发现应用服务器写入速度远大于复制的速度，尤其是在主节点和复制节 点存在网络拥堵的情形下。一旦这种情况发生，如果数据集大到一定程度，复制节点很有可能永不再 与主节点同步。
   

• 自动切换:为什么需要这个？内存数据库每秒处理的请求比一般数据库通常多100倍，这就意味着每增加一秒宕机时间就会延迟更多的请求处理并给用户带来不好的用户体验。在实现自动切换时一定要遵循下面的原则：
  1.确保主存储节点一旦失败就立马切换到备用复制节点。这一般基于成熟健壮的看门狗技术 （watchdog），看门狗持续的监控节点，一旦失败就切换到健康的复制节点。
  2.对于你的应用程序而言切换过程要尽量透明；最理想的情况是不需要更改任何配置。更高级的解决方案是仅仅修改DNS中存储节点的IP地址，确保修复过程在几秒钟之内完成。
  3.自动切换应当基于Quorum并且是完全一致(fully consistent)或最终一致（eventually consistent）的。讨论下面继续：
   

2. 网络分裂过程中和完成后的一致性

网络分裂（network splits)在云中频繁发生，对地球上的分布式存储系统而言也是最复杂的问题。一旦发生分裂，应用程序可能只会发现内存数据库的部分节点；同时，每个内存NoSQL数据库节点也很有可能只能发现一部分的其他节点。

为什么说这是一个非常严重的问题呢？如果你的数据库包含一 些隐蔽的设计缺陷，当网络分裂发生时，应用程序很可能会写入错误的节点。这意味着，当情况恢复时，应用程序发起的写入就会丢失。这对基于内存的 NoSQL数据库来说这是一个非常有意义的话题，因为基于内存的NoSQL数据库每秒的写操作远大于其他的NoSQL数据库系统。

一个设计得当的基于内存的NoSQL是什么样子的呢？很不幸，你只能从下面两个非常糟糕的候选中选择一个：

1. 如果基于内存的NoSQL数据库是完全一致（fully consistent）的，在某些情况下你是不允许写入任何内容的，除非网络分裂恢复。
2. 如果基于内存的NoSQL数据库是最终一致（eventually consistent)的，应用程序可以对“读”请求采用quorum方法——返回一个值或者阻塞。
    

3. 数据持久化

尽管基于内存的NoSQL解决方案提供多种复制选择，你仍需要着重考虑数据持久化和备份，原因如下：

• 或许你不希望为内存复制提供额外支出，但是仍希望将数据保存在某个地方并且在遇到节点故障时能够将数据恢复（即使恢复速度很慢）。
• 你一定希望在遇到任何故障时都能将数据恢复并且希望保留另外一个选择——将数据保存在另外一个安全的地方，即使数据不能与最新的的修改同步。
• 还有一些采用数据持久化的其他理由，例如为了测试将数据从生产环境导入到过渡环境等

现在你已经确信数据持久化是必要的，在大多数云环境中你应当使用附属在云主机上的存储设备（像AWS的EBS、Azure的Cloud Derive等）。如果你将数据保存在本地硬盘，当遇到节点故障时你就会丢失数据。

一旦数据得到持久化保存，你最大的挑战将变成：在将改变实时写入到持久化存储的同时保证内存NoSQL数据库的速度。