Sirius是Comcast公司推出的基于分布式内存的集群存储，Comcast是美国最大的有线电视和视频提供商，在Comcast，Sirius主要用来存储在线视频的描述信息，这么个需求挺简单的，但是Comcast觉得用传统的缓存来维护挺麻烦，于是打算利用单一存储来一劳永逸的解决该问题，就造了这么个轮子，把所有需要高并发低延迟的信息都放到单一存储里。
下边看下Sirius设计上有哪些特点。Sirus支持多数据中心同步，先天具备异地容灾性。由于是全内存方案，先天具备高并发和低延迟，同时通过日志来提供灾难恢复机制。在副本设计上，Sirus采用Multi-Paxos协议来确保全局写入请求的固定顺序，每个节点均提供本地存储用于存放日志，当节点启动时，所有日志会被加载到内存中。除此之外，Sirus还设计了一种称为"Catch Up"的协议用来弥补因为挂掉而漏掉的请求：每个节点定期选择集群其他节点返回部分日志用于比对，Catch Up协议也可以用来让部分没有加入Paxos的节点也提供多副本，例如下图中有4个集群A,B,C,D，分别在不同的数据中心。A集群采用Paxos状态机复制，B和C都是A的跟随者，会定期从A的任一节点根据Catch Up协议提取日志，D是新机房，没有配置加入Paxos集群，因此配置为根据Catch Up协议从B或者C来获取日志。图中实线是Paxos协议，虚线则为Catch Up协议。 因此Sirius在设计上的主要特点就是灵活的跨机房的多副本机制。
由于Catch Up协议的存在，Sirius需要日志能够提供检索服务，既根据日志ID提取日志数据，因此Sirius采用了一种类似Bitcask的简易索引。Bitcask在2010年左右分别由豆瓣，Basho Riak，以及俄罗斯Reverbrain几乎同时提出的日志型索引，针对WAL日志提供O(1)的IO复杂度，代价是内存索引。Sirus由于日志记录是顺序ID，因此省掉了这一部分内存开销。
Sirus没有外部依赖，Multi-Paxos是自行实现，整体代码用Scala构建在Akka集群上。本文之所以介绍Sirus项目，是因为这又是一个状态机复制的现成例子，尤其还提供跨机房容灾机制，并且经过商业检验。由于它并不具备多分区能力，因此也无法存放更多的数据。 仅仅针对一个特定的需求，ComCast就造出这样的轮子，只能认为他们的工程师对于基础架构设计上有洁癖。不论如何，这都是值得我们参考和学习的设计之一。看着这些传统企业向互联网转型，笔者同时也想到了国内的湖南卫视，分别推出的容器PaaS云和Redis分布式集群Cerberus，在某些方面，尤其是“洁癖”上，还真跟ComCast有些像。
