Cassandra作为事件存储的最佳选择之一

Cassandra特点是写入快，而在一个事件驱动架构EDA或Event sourcing中，我们需要一个可伸缩扩展的数据库来保存快速发生且不断增长的事件日志，将系统正在发生所有事件都进行保存，然后在适当时候进行事件回放，或者需要时进行数据挖掘分析。

这其中涉及多个重要技术环节：
首先如何第一时间把用户操作事件截取下来，这可以参考LMAX架构，使用disruptor对事件进行分发，也可以使用JdonFramework的事件元注释通过DCI对用户的输入事件进行异步快速分发。

其次，是否直接分发到Cassandra？简单系统可以，但是复杂系统最好分发到一个消息中心，然后由消息中心分发保存到Cassandra，这样弹性可扩展性更好 。这个消息系统可以使用ActiveMQ等通用，也可以使用开源Apache Kafka，值得注意的是，Event Sourcing和ESB事件总线SOA两种架构对消息系统要求不同，前者要求高性能高吞吐量；后者要求高灵活性高可配置型，灵活性环节增多，意味响应延迟性可能增加。

各个渠道的操作事件汇聚保存快速写入到Cassandra后，如果需要事件日志回滚，比如查询某段时间内的事件，就涉及到Cassandra操作了，Cassandra: Lessons Learned | Javalobby一文谈到了这方面细节：

这是一个SOA架构WSO2中采取Cassandra作为业务活动监视Business Activity Monitoring，其实就是一种类似ES架构。

Cassandra记录事件日志数据格式是：
Event Id | Server:esb12 | time:08:00
Cassandra:作为事件存储的最佳选择
这段格式记录的是每台ESB服务器如esb12的处理事件的时间，如8点。

这是esb12事件发生写入Cassandra的原始日志格式，如果我们需要事件回滚，查询服务器esb12在08:00和09:00之间发生的事件，直接从这个原始格式查询性能是慢的，该文介绍了如何在原始日志格式上建立一种索引，以便进行复杂查询的方法。

[该贴被banq于2011-12-07 14:33修改过]