浅谈高可用分布式流数据存储设计

单体服务应用只需一个数据库存储数据就足够了。随着业务需求的增多，服务从1个增长到N个，数据也需要分库分表来存储，若基于容灾等方面考虑，还需要做多个副本。
此外不同的业务场景需要用到不同结构的数据存储，比如搜索需要用到ElasticSearch，存储分析需要用到Hive集群，在线业务需要用到K-V(键-值，NoSQL)存储和MySQL存储，同时这些数据还要在一定的业务场景下做到实时同步。
早期的小规模业务，单体服务配合单个数据库即可满足业务需求。而当下，数据库分库分表，并采用读写分离和分布式的架构模型，同一份数据被转换成各种特定的数据格式，存放在各种各样的数据库中，会消耗大量的存储和计算资源。为解决这一数据治理乱象，分布式流数据存储应运而生。
在这种情况下，数据就存在诸多问题：
当数据在各种场景下ETL（Extract-Transform-Load，数据抽取、转换和加载）会造成严重的资源浪费；
每份数据都有快照备份，占用极大的存储空间；
当某一份数据不止服务于一个微服务时，一旦业务调整，一份数据的变动将会影响下游的数据变动，就会出现严重的耦合问题。
冗杂数据随业务扩张而呈指数增长，数据治理显得尤为重要。分布式流数据存储平台，便可应对上述问题。
前后端数据在一个时间点产生，当我们对某个特定的数据做变更，并将其放入到流存储平台里面，其他服务调用数据时，无需经过ETL即可直接使用。需要注意的是，流数据不能服务于终端业务，因为流数据在平台中是查询不友好的，无法按照业务场景去查询。
对于以上的应用背景分析，那么其存储特性也就很显而易见了：
有序性：数据必须是有序的，因为数据的读取和处理是按照写入的顺序进行的；
扩展性：数据只能在尾部写入，写入则无法变化；
性能：具有高性能、可靠性等分布式系统特性；
一致性：不需强一致性，要求顺序一致性即可；
容量：因存储所有数据，要求近乎无限的容量。
基于上述存储特性，可以有针对性地设计流数据存储平台的核心组件。