分布式数据服务
分布式领域数据存储：
1：高可用性，当遇到网络或者系统故障时，系统仍然保持可用
2：高扩展，当数据规模变大时，数据存储系统能够自动适应这种变化
3：高性能，当数据规模和访问规模变大时，性能不受大的影响
4：成本，通过成本反映出系统设计是合理的
5：安全，遇到各种系统和人为故障时，数据不丢失
一：MySQL
MySQL本身不是分布式系统，其支持的数据复制技术，本质上是为了数据容灾使用，但目前基于主从复制进行读写分离，减少单机的读压力。
数据存储不支持分片，只能通过分库分表的方式进行横向扩展，目前应用层也不支持分库分表的路由，即使分表，拆分表的时候还是会遇到很多问题
云托管的RDS本质上还是基于ECS+云盘搭建的，数据的增长、备份、性能、迁移、升级、只读实例、磁盘容量、Binlog延迟还是会显露出来。
经过这些创新，传统MySQL的弊端被解决了，比如同步延迟、备份、成本、分库分表、性能。
未来，可以将核心数据库迁移至云原生数据库，保障核心业务的稳定性和扩展性，而对于非OLTP业务可以选择其他数据库，且制定MySQL应用规范，明确哪些业务模式使用MySQL，索引正确设计、容量规划、SQL语句使用规范等等。
二：Redis
Redis是K/V数据库，它基于单线程、内存操作，所以性能非常高。另外支持丰富的数据结构，比如字符串、Hash、List、集合，应用场景非常广泛。
它通过AOF和RDB保障数据持久化，通过复制技术进行数据备份，也支持通过哨兵和分区提供高可用性和容量伸缩，通过LUA脚本支持多条命令的事务操作。
1：存储，比如用户积分、文章数等数据，这些数据不能丢
2：缓存，比如用户文章列表数据，需要考虑缓存穿透和雪崩等问题
3：消息队列，目前逐步替换为Kafka等纯消息系统
后续确定Redis使用规范，拆分存储和缓存场景，基于统一Lib包，就能解决大部分问题。
三：Elasticseach
Elasticseach是一个近实时的分布式搜索引擎和分析引擎。
作为一个搜索引擎，目前在开源领域已经是的数据库了；基于倒排索引，具有很强的检索能力，所以不管是应用还是在大数据领域，它都是一个非常通用的分析引擎。
近实时表示Elasticseach应用场景必须要有所了解，它不支持ACID，所以无法是一个OLTP数据库，但使用压力小了很多，在做策略分析、后台应用、即时查询上有很广泛的场景。
作为一个分布式应用，通过副本集机制解决高可用的问题，能够解决单机故障的问题，但如果数据被误删除，还是需要有备份机制，比如Elasticseach的快照机制。
副本集的同步终达到一致性，为了写入性能，也可以配置主节点写入完成即返回给客户端。
在容量可扩展方面，可以采用分片机制解决容量横向伸缩的问题，将数据分到不同节点的不同分片上，如果要调整分片，需要reindex。
在性能方面，通过多副本集节点分担查询压力。也可以使用专门的Transport节点分担date Node节点的压力，将分片查询，副本查询等路由和合并动作的结果汇总起来。
Elasticseach是ELK解决方案的一部分，其还包括很多服务，包括Filebat，Kibana，Logstash，在大数据领域也是很好的一个方向。
Elasticseach是在ELK上搭建的三节点服务，由于规模问题，目前也很少使用分片技术。核心是文章大宽表，用户大宽表。
结合了搜索场景和分析场景，通过Binlog+Canal+Kafka+Go服务将MySQL多个表汇总到一个大宽表，主要是文章信息的大宽表，一方面是满足搜索场景，另外满足策略和应用场景。
四：Kakfa
Kakfa是一个分布式的高吞吐消息队列，订阅/消费模式追求的是高性能，而非存储容量。但其日志本身具有重放功能，也可以理解为一个分布式存储系统。
Kafka的核心功能包括：解耦、消峰、缓存，应用场景极为广泛，是系统不可缺少的一个组件。
作为分布式系统，它也有副本和分区机制，从而保障高可用和高吞吐。通过segment顺序写，保障了写性能非常高，而基于消费组组的概念，消费者吞吐能力也能横向扩展。同时每个broker都能负责查询，提升了吞吐能力
Kafka基于Zookeeper做很多分布式管理功能，包括Leader选举，负载均衡，Meta存储。
五：MongoDB
MongoDB是一个分布式的文档数据库，其目标是一个支持ACID事务的分布式数据库，因为是面向文档，所以模式非常灵活，结构松散，使用场景很规范，相比MySQL，其二进制的存储模式，压缩比非常高，存储成本会大幅减少，同时基于WiredTiger引擎，能够创建各种类型的索引，甚至子文档也能创建索引，从而提升查询性能
1：高可用性，当遇到网络或者系统故障时，系统仍然保持可用
2：高扩展，当数据规模变大时，数据存储系统能够自动适应这种变化
3：高性能，当数据规模和访问规模变大时，性能不受大的影响
4：成本，通过成本反映出系统设计是合理的
5：安全，遇到各种系统和人为故障时，数据不丢失
一：MySQL
MySQL本身不是分布式系统，其支持的数据复制技术，本质上是为了数据容灾使用，但目前基于主从复制进行读写分离，减少单机的读压力。
数据存储不支持分片，只能通过分库分表的方式进行横向扩展，目前应用层也不支持分库分表的路由，即使分表，拆分表的时候还是会遇到很多问题
云托管的RDS本质上还是基于ECS+云盘搭建的，数据的增长、备份、性能、迁移、升级、只读实例、磁盘容量、Binlog延迟还是会显露出来。
经过这些创新，传统MySQL的弊端被解决了，比如同步延迟、备份、成本、分库分表、性能。
未来，可以将核心数据库迁移至云原生数据库，保障核心业务的稳定性和扩展性，而对于非OLTP业务可以选择其他数据库，且制定MySQL应用规范，明确哪些业务模式使用MySQL，索引正确设计、容量规划、SQL语句使用规范等等。
二：Redis
Redis是K/V数据库，它基于单线程、内存操作，所以性能非常高。另外支持丰富的数据结构，比如字符串、Hash、List、集合，应用场景非常广泛。
它通过AOF和RDB保障数据持久化，通过复制技术进行数据备份，也支持通过哨兵和分区提供高可用性和容量伸缩，通过LUA脚本支持多条命令的事务操作。
1：存储，比如用户积分、文章数等数据，这些数据不能丢
2：缓存，比如用户文章列表数据，需要考虑缓存穿透和雪崩等问题
3：消息队列，目前逐步替换为Kafka等纯消息系统
后续确定Redis使用规范，拆分存储和缓存场景，基于统一Lib包，就能解决大部分问题。
三：Elasticseach
Elasticseach是一个近实时的分布式搜索引擎和分析引擎。
作为一个搜索引擎，目前在开源领域已经是的数据库了；基于倒排索引，具有很强的检索能力，所以不管是应用还是在大数据领域，它都是一个非常通用的分析引擎。
近实时表示Elasticseach应用场景必须要有所了解，它不支持ACID，所以无法是一个OLTP数据库，但使用压力小了很多，在做策略分析、后台应用、即时查询上有很广泛的场景。
作为一个分布式应用，通过副本集机制解决高可用的问题，能够解决单机故障的问题，但如果数据被误删除，还是需要有备份机制，比如Elasticseach的快照机制。
副本集的同步终达到一致性，为了写入性能，也可以配置主节点写入完成即返回给客户端。
在容量可扩展方面，可以采用分片机制解决容量横向伸缩的问题，将数据分到不同节点的不同分片上，如果要调整分片，需要reindex。
在性能方面，通过多副本集节点分担查询压力。也可以使用专门的Transport节点分担date Node节点的压力，将分片查询，副本查询等路由和合并动作的结果汇总起来。
Elasticseach是ELK解决方案的一部分，其还包括很多服务，包括Filebat，Kibana，Logstash，在大数据领域也是很好的一个方向。
Elasticseach是在ELK上搭建的三节点服务，由于规模问题，目前也很少使用分片技术。核心是文章大宽表，用户大宽表。
结合了搜索场景和分析场景，通过Binlog+Canal+Kafka+Go服务将MySQL多个表汇总到一个大宽表，主要是文章信息的大宽表，一方面是满足搜索场景，另外满足策略和应用场景。
四：Kakfa
Kakfa是一个分布式的高吞吐消息队列，订阅/消费模式追求的是高性能，而非存储容量。但其日志本身具有重放功能，也可以理解为一个分布式存储系统。
Kafka的核心功能包括：解耦、消峰、缓存，应用场景极为广泛，是系统不可缺少的一个组件。
作为分布式系统，它也有副本和分区机制，从而保障高可用和高吞吐。通过segment顺序写，保障了写性能非常高，而基于消费组组的概念，消费者吞吐能力也能横向扩展。同时每个broker都能负责查询，提升了吞吐能力
Kafka基于Zookeeper做很多分布式管理功能，包括Leader选举，负载均衡，Meta存储。
五：MongoDB
MongoDB是一个分布式的文档数据库，其目标是一个支持ACID事务的分布式数据库，因为是面向文档，所以模式非常灵活，结构松散，使用场景很规范，相比MySQL，其二进制的存储模式，压缩比非常高，存储成本会大幅减少，同时基于WiredTiger引擎，能够创建各种类型的索引，甚至子文档也能创建索引，从而提升查询性能
