消息推送系统使用Cassandra存储数据

[tangtang2013]

trafficstars

数据量大概是每天5亿级别，移动终端app（android，ios）从Cassandra获取推送消息。 1.每天5亿访问量 2.历史消息只保存15天，大概600G的数据 3.每天中午晚上是访问高峰期 4.峰值可能会有几十万

我原本考虑使用levedb做存储，使用thrift网络层，通过消息id分片。后来想到Cassandra本身使用的就是SSTable，支持水平扩展，扩展非常easy，所以就思考使用Cassandra的解决方案。

请教使用Cassandra是否合适？非常感谢！！！

[codefollower]

使用Cassandra前需要先考虑第一个问题：你的系统是需要强一制还是允许最终一致？ 如果是需要强一制的，目前是建议用HBase这类方案先。 否则可以继续往下看: 每天5亿访问量是写的多，还是读的多，需要复杂查询吗？比如需要join和频繁的范围查询吗？ Cassandra适合频繁写，简单按key读的场景，频繁的范围查询或做各种聚合现在它还不适合。

600G的数据量很一般，只存这点数据Cassandra没什么压力的。

[tangtang2013]

目前业务延时都是可以接受的，消息推送不是要求实时性特别强的业务。 1.弱一致性，读写都设置为one都行。 2.读写应该对半，查询不复杂 3.按照目前的业务，只需要两张表（用户表，消息表） 4.消息表（msgid，userid，status，content），用户每次取出一条未读消息 5.用户表（userid，）用于统计用户消息推送的一些数据 6.每次用户拉取一条消息，修改消息状态 7.消息只需要保留15天，超过15天把这些消息清除

目前我考虑这样使用，如果Cassandra符合要求，运行稳定，我们其他业务可以考虑使用Cassandra。 非常感谢！！！

[codefollower]

需求不复杂，可以先在测试环境跑一下看看， 数据量主要集中在消息表，建表时，以userid、msgid为primary key， 这时Cassandra会把userid当成partition key，而msgid是clustering column， 消息会按msgid聚簇在一起，如果按时间降序排，第一条就是最新的消息。 如果msgid是有时间序的，Cassandra更适合，因为它最擅长时间序类型的应用。

Cassandra支持TTL的，把TTL设为15天，会帮你自动删除的。