这是来自OpenCredo使用Cassandra存储事件的经验分享PDF。
所谓事件服务实际是提供事件存储和查询的微服务。之所以需要事件服务，原因如下： 1.捕获成千上百的平台事件和业务事件 2.异步触发下游处理 3.以不平常方式定制标准处理方式 4.提供系统领域内的事务日志 5.分析 6.系统测试
设计原则是简单、解耦、可扩展和容错。
起初Event服务的API版本1设计为存储和读取一个事件。 POST /api/events/ GET /api/events/{eventId}
一个事件Event的样本数据：
{
"type" : "DEMOENTITY.DEMOPROCESS.DEMOTASK",
"source" : "demoapp1:2.5:981a24b3-2860-40ba-90d4-c47ef1a70abe",
"clientTimestamp" : 1401895567594,
"serverTimestamp" : 1401895568616,
"platformContext" : {
"id" : "demoapp1",
"version" : "2.5"
},
"businessContext" : {
"channel" : "WEB",
},
"payload" : {
"message" : "foo",
"anInteger" : 33,
"bool" : false
}
}
|
Event事件的Cassandra数据表设计：
Event服务API 版本2是查询多个事件和通知 GET /api/events?{queryString} {queryString}由下面字段组成：start, end, startOffset, limit, tag, type,order
举例： GET /api/events?start={startTime}&end={endTime} GET /api/events?startOffset=3600000&type=someType
如何对时间序列Time series建模呢？ 使用时间戳作为集群列。
好处是：简单，对简单数据结构很适合，好的读写性能。 缺点是：分区大小的限制(2 billion cells)，灵活性差 查询限制。
使用Time bucket：
特点：查询变得稍微更复杂，写性能不影响，读取（较）慢。
原文还提供查询和分页查询模型的设计：PDF [该贴被banq于2014-12-08 16:05修改过]