方案
- 本地缓存分布式缓存
可缓存热门商品，热门商品html页面
涉及缓存一致性，缓存击穿，缓存雪崩 - nginx负载均衡
工作在网络第7层，支持50000个并发 - 数据库读写分离
读库可以有多个，通过同步机制把写库的数据同步到读库
可使用Mycat数据库中间件
涉及数据库同步，数据库一致性问题 - 按业务分库
不同业务的数据存不同的库，使业务之间的资源竞争降低， - 大表拆成小表
按照商品id进行hash
支付记录按小时分表，使用用户id或记录编号来路由数据
分库分表的管理和请求分发由Mycat实现，读写分离由网关和消息队列实现，查询结果的汇总由数据库接口实现 - LVS或F5使多个Nginx负载均衡
工作在网络层第4层
LVS是单机版，可支持几十万的并发请求，需要与keepalived配合 - DNS轮询负载均衡
实现机房间的负载均衡（域名配多个ip），做到机房级别的水平扩展 - nosql和搜索引擎
海量文件用HDFS解决
海量数据用HBase、Redis解决
全文检索用ElasticSearch
多维分析用Kylin、Druid - 大应用拆分成小应用
以小应用为单位升级功能，做到独立升级 - 复用的功能抽离成微服务
用户管理、订单、支付、鉴权等
Redis集群
原理
关于redis的集群化方案 目前有三种
（1）Twitter开发的twemproxy
（2）豌豆荚开发的codis
（3）redis官方的redis-cluster
Redis Cluster是一种服务器Sharding技术，采用slot(槽)的概念，一共分成16384个槽。对于每个进入Redis的键值对，根据key进行散列（CRC16后16384取模），分配到这16384个slot中的某一个中。每个slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移
官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点，如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点。
整个cluster被看做是一个整体，客户端可以连接任意一个node进行操作，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node
容错
如果半数以上master节点与master节点通信超时(cluster-node-timeout),认为当前master节点挂掉，推举当前节点下某从节点为新master
如果集群任意master挂掉,且当前master没有slave.集群进入fail状态
如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态
一致性
redis集群存储流程
1、你的客户端写给主服务器节点 B
2、主服务器节点B向您的客户端回复确认。
3、主服务器节点B将写入传播到它的从服务器B1，B2和B3。
如果在写入B1、B2、B3时B崩溃，则数据丢失。通过强制数据库在回复客户端之前刷新磁盘上的数据，这样可以提高一致性，但这通常会导致性能极低
持久化
redis有相对的数据持久化的方案 由两种方式构成 aof & rdb
aof把每一次写操作以追加的形式记录在其中以文件的形式刷到磁盘里，缺点是文件的大小会随着时间线性增长，一段时间之后就会变得很大，恢复数据慢
rdb就是每隔一段时间 对内存中的数据做一次快照 保存在rdb文件中 但是问题是 如果数据量很大的话 rdb它要保存一个完整的数据集 是一个大的工作 如果时间间隔设置的太短 那么严重影响redis的性能 但是按照常规设置的话 如5分钟一次 那么如果宕机或者重启 就会基于上次做rdb的时间
从而丢失分钟级的数据
Mysql集群
原理
主将更改操作记录到binlog里
从将主的binlog事件（sql语句） 同步本机上并记录在relaylog里
从根据relaylog里面的sql语句按顺序执行
用途
- 读写分离
- 数据实时备份
- 高可用HA（HA(High Available)，高可用性集群，是保证业务连续性的有效解决方案，一般有两个或两个以上的节点，且分为活动节点及备用节点）
- 架构扩展
主从形式
- 一主一从
- 一主多从，最常见实现读写分离和HA
- 多主一从，备份
- 双主复制，任何一方所做的变更，都会通过复制应用到另外一方的数据库中
- 级联复制，可以让3~5个从节点连接主节点，其它从节点作为二级或者三级与从节点连接，这样不仅可以缓解主节点的压力，并且对数据一致性没有负面影响。
主从复制模式
- 异步模式（async-mode）
主节点不会主动push bin log到从节点 - 半同步模式
主节点只需要接收到其中一台从节点的返回信息，就会commit。需要master 和slave 安装插件开启半同步模式。 - 全同步模式
主节点和从节点全部执行了commit并确认才会向客户端返回成功
mongoDB集群
MongoDB也是BTree索引
TTL索引是一种特定的数据块，请求赋予时间范围的方式，它指定一个时间点，超过该时间点数据变成无效。
副本集
主服务器负责整个副本集的读写，副本集定期同步数据备份，副本集中的副本节点在主节点挂掉后通过心跳机制检测到后副本节点就会选举一个新的主服务器
复制原理
mongodb的复制至少需要两个节点。其中一个是主节点，负责处理客户端请求，其余的都是从节点，负责复制主节点上的数据。
mongodb各个节点常见的搭配方式为：一主一从、一主多从。
主节点记录在其上的所有操作oplog，从节点定期轮询主节点获取这些操作，然后对自己的数据副本执行这些操作，从而保证从节点的数据与主节点一致。
副本集特征
N 个节点的集群
任何节点可作为主节点
所有写入操作都在主节点上
自动故障转移
自动恢复
bully算法选举主节点
选择最后操作时间戳最新（保证数据是最新的）的服务器节点作为主节点。
读取策略
Primary - 从主节点读取；
secondary - 从从节点读取；
nearest - 从网络延迟最小的节点读取；
primaryPreferred - 基本上从主节点读取，主节点不可用时，从从节点的读取；
secondaryPreferred - 基本上从从节点读取
分片
分片(sharding)是指将数据拆分，将其分散存在不同的机器上的过程。将数据分散到不同的机器上，不需要功能强大的大型计算机就可以储存更多的数据，处理更多的负载。
设置分片时，需要从集合里面选一个键，用该键的值作为数据拆分的依据。这个键称为片键(shard key)。
组件
分片(Shard)：用于存储实际的数据块，实际生产环境中一个shard server角色可由几台机器组个一个replica set承担，防止主机单点故障；
每个shard包含分片数据的子集，每个shard可以部署一个副本集
配置服务器(Config Server)：mongod实例，存储了整个 ClusterMetadata，其中包括 chunk信息；存储集群的元数据，这些数据包含了集群数据集到各分片的映射关系。查询路由就是通过这些元数据到特定的分片上执行指定的数据操作
查询路由(Routers)：前端路由，客户端由此接入，且让整个集群看上去像单一数据库，前端应用可以透明使用；
片键
MongoDB的数据划分，是以集合级别为标准。分片通过片键(shard key)来划分集合数据。
MongoDB将shard keys值按照块（chunks）划分，并且均匀的将这些chunks分配到各个分片上。MongoDB使用基于范围划分或基于散列划分来划分chunks的。
片键决定了集群中一个集合的文件在不同的片键中的分布，片键字段必须被索引，且在集合中的每条记录都不能为空，可以是单个字段或者是复合字段
被选为片键的字段必须有足够大的基数，或者有足够多的不同的值，对于单调的递增的字段如果ObjectID或是时间戳，哈希索引效果更好
ElasticSearch集群
https://blog.csdn.net/zwgdft/article/details/54585644
数量级：2-4台机器几千万到数十亿，几十到上百节点数据规模可能达到千亿或更多
节点类型
1、主节点/候选主节点
集群中会从候选主节点中选举出一个主节点，主节点负责创建索引、删除索引、分配分片、追踪集群中的节点状态等工作
2、数据节点
数据节点负责数据的存储和相关具体操作，比如CRUD、搜索、聚合。所以，数据节点对机器配置要求比较高
3、客户端节点
客户端节点就是既不做候选主节点也不做数据节点的节点，只负责请求的分发、汇总等等，也就是下面要说到的协调节点的角色。这样的工作，其实任何一个节点都可以完成，单独增加这样的节点更多是为了负载均衡。
4、协调节点
协调节点，是一种角色，而不是真实的Elasticsearch的节点，你没有办法通过配置项来配置哪个节点为协调节点。集群中的任何节点，都可以充当协调节点的角色。
分片（Shard），是Elasticsearch中的最小存储单元。一个索引（Index）中的数据通常会分散存储在多个分片中，而这些分片可能在同一台机器，也可能分散在多台机器中。这样做的优势是有利于水平扩展，解决单台机器磁盘空间和性能有限的问题。ElasticSearch推荐的最大JVM堆空间是30~32G, 所以把你的分片最大容量限制为30GB
脑裂问题
出现多个主节点
解决方法：Master 和 dataNode 角色分开，配置奇数个master
Hadoop
核心
HDFS
Hadoop Distributed File System，分布式文件存储系统。
NameNode：负责总体调度，处理协调请求等。接受客户端读写服务，存放元数据（DataNode存储的位置等基本信息，fsimage和edits文件）fsimage是namenode格式化时产生的，edits是用户操作增删改查的时候生成的日志
DataNode：存储节点，会备份，一般本地2分，其他服务器一份
数据块:存储单元，一般64M（hadoop2中是128M）
MapReduce
Step 1：从本地HDFS读取文件输入的内容，每个输入文件被切分成一定大小的数据块Block（1.0版本默认64M）；
Step 2：每个被切分的数据块Block会产生对应的Map任务，用户可以定义map函数，对被切分的数据使用map函数解析成一个key/value格式的数据；
Step 3：对每个map任务得到的key/value格式的数据按照不同的分区，通过网络传输到不同的Reduce节点；
Step 4：对多个map任务输出的结果进行排序、合并，然后通过reduce函数进程处理得到最新的key/value结果；
Step 5：将Reduce输出的结果保存到文件系统中。
yarn
YARN：任务分配和集群资源管理框架
RabbitMQ集群
https://www.cnblogs.com/xishuai/p/rabbitmq-cluster.html
RabbitMQ基于Erlang编写，本身不需要像ActiveMQ、Kafka那样通过ZooKeeper分别来实现HA方案和保存集群的元数据。
RabbitMQ集群会始终同步四种类型的内部元数据（类似索引）： a.队列元数据：队列名称和它的属性； b.交换器元数据：交换器名称、类型和属性； c.绑定元数据：一张简单的表格展示了如何将消息路由到队列； d.vhost元数据：为vhost内的队列、交换器和绑定提供命名空间和安全属性； 因此，当用户访问其中任何一个RabbitMQ节点时，通过rabbitmqctl查询到的queue／user／exchange/vhost等信息都是相同的。
如果用户连接的节点没有消费数据，节点会作为路由传输消费节点的数据
687
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
