背景
日志，角色不同，出发点和认识的角度也不同
RD使用日志，首先是为了调试程序，当程序上线后，日志是为了记录err和trace。
PM可以通过日志分析，可以得出业务指标相关的统计情况。
日志的作用大致有三：异常、trace、统计。
日志使用的痛点
使用日志时大部分的场景或特点如下：
1.日志为纯文本，即可读。
2.日志分散在各个机器上，或者同步到某一台机器。
3.某某发现一个问题，让某某去查log。
这里有几个问题，或者说提高点
1.文本冗余度太大，浪费资源，如果转换为二进制，预估有5倍的收益。
2.日志分散，查找效率低，即使集中，在没有具体时间点情况下，扫描日志会很慢。
3.日志分析难度大，谁写的日志谁来查，查到和肉眼找到还差一步...
目标
所以，我们可以设计这样一个日志系统
1.支持海量数据的日志存储（TB二进制）
2.日志二进制、结构化
3.查询速度快，难度低
设计
读写日志
日志查询过程经分解和总结共性后，几乎是下边三种情况
1.K-V查询，比如基于某个消息ID，查询一条记录。
2.集合查询，比如查询某个用户的消息记录。
3.集合range查询，比如查询某个用户0点到1点消息记录。
那么，ssdb是非常适合这三个需求的。
日志系统具有写多读少的特定，再基于磁盘存储的业界主流方案，LSM是适合的，
而SSDB的存储依赖的leveldb正好属于LSM系。
日志二进制
一个大的日志是没办法人用肉眼扫描的，所以不如使用二进制代替以节约空间，但是日志
会随着需求的变化，格式也可能会变化，所以必须考虑二进制向文本反序列化时的
兼容性问题，那么protobuf是非常适合这个需求的。
海量日志
Sharding
业务的sharding，一个业务对应N个存储服务，N个业务对应N*N个存储服务，单一存储服务内只
承载一个业务。
磁盘的sharding，一块盘对应N个存储服务，N块磁盘对应N*N个存储服务。
0 1 2 3 4
db |_____|_____|_____|_____|
0 1t 4t
disk |_______|_______________|
Resharding
扩容时增加存储服务即可。
缩绒时删除存储服务即可。
Failover
存储服务挂了后重启就可以。
由于存储的是日志，在机器发生故障后是允许丢的，所以数据不做迁移，只需将相应的服务等比例
迁走即可。