后端存储技术名词

分片：数据量大（分库分表等）

分片算法：范围分片，Hash分片

并发高：新增实例（业务维度拆分，同业务拆分）

高可用HA：主从复制

状态不一致：复制状态机技术（快照+日志）

Grousip:  流言协议

冗余：增加副本

去中心化设计：无主模式

版本号技术：无主模式选举 Redis

元数据库：热点数据倾斜，文件存储

Raft： 复制状态机保证数据可靠，心跳和选举保证高可用

半数投票： 奇数副本，半数投票通过当Leader

NWR： W+R>N

脑裂：主库宕机，主库和从库二份不一样的数据，无法自动恢复

 

MySQL：读写分离、分库分表、归档、复制（同步复制、异步复制、半同步复制： 至少保证复制1台机器）、备份安全（全量备份与增量备份）、不停服数据迁移

分布式ID：Snowflake,Twitter分布式ID算法

订单号服务：日志记载主键防重，三方对账

CAS： 比较交换，避免ABA问题

 

Cache: Read/Write Through,  Cache Aside

分片：Hash分片

高可用HA: 主从复制，复制状态机理论 

Redis集群不适合大规模集群原因：Grousip协议，主挂了从节点版本号选举技术 =》代理模式&客户端寻址模式

Canal： 订阅Binlog，同步Redis

 

ES:  倒排索引，索引（表），文档 （行）、字段（列）、Mapping

 

分布式文件系统： 元数据、分块、版本号选举（主挂了，从节点选举）、整块复制

海量数据：Kafak、HDFS、实时流计算(Flink,Storm)、离线批计算（MapReduce、Spark)

< GB:  MySQL    10GB:  优先考虑ES, 后考虑HBase等  TB: HDFS

 

一致性方案

实例状态保持一致：实例宕机或网络分区故障

一致性与可用性原则：如无必要，勿增副本

解决一致性代价：可用性降低、性能下降、用户体验变差或增加系统复杂度  =》不要人为制造一致性难题

 

副本设计：

不同格式或数据结构存储多个副本

不同类型的外部存储多个副本

本地磁盘或内存中缓存数据副本

常见错误示例：

1、为写代码方便，A表部分字段，B表也存储1份

2、集群元数据存储Zookeeper，为方便管理控制台，MySQL也保存1份

3、不考虑系统性能要求，Redis和内存中都缓存数据

 

一致性：一个整体对外所表示的一致性，分布式系统内部可以存在不一致状态，这种状态外部不可见

难点1：如何处理操作失败的情况？ 

A节点更新成功，B节点更新失败，系统保持一致，需将这种不一致隔离在系统内部，不让外部感知，并尽快修复不一致状态；

修复策略：重试/回滚  =》 代价非常大

难点2：一个节点不可用，如何保证一致性

难点3：网络分区情况，保证系统一致性

 

BASE理论：允许不一致的中间状态被外部可见，但需要在短时间内恢复为一致状态

牺牲一致性需要守住两个底线：防止脑裂和要保证单调读写 （状态版本号）

 

减缓DB压力

加速查询请求

赋能应用服务

主节点：读写

从节点： 分流读压力+容灾