中间件

redis

spring-data-redis

redisTemplate

五种数据类型操作

setoperations BoundSetOperations

zsetoperations BoundListOperations

hashoperations BoundSetOperations

listoperations BoundHashOperations

事务操作封装

针对数据的序列化/反序列化

jdk pojo对象序列化

redisTemplate 字节方式序列化的方式存储

string 序列化存储

StringRedisTemplate 字符串的方式序列化存储

json 序列化存储

删除key，指定过期时间

发布/订阅

只能做简单的发布订阅，且发布者和订阅者必须实时连线，只支持1对N

缓存经典问题

缓存雪崩

缓存突然大面积失效，原因可能是集群环境节点出问题，过期时间问题，

解决方式1 集群，2热点数据永不过期，3过期时间随机，

缓存击穿

缓存中没有数据，请求直接打向数据库，数据库承受不住

解决方式 1 热点数据永不过期，2如果是一定要访问的，那么加锁执行，拿到锁的优先执行

缓存穿透

缓存没有，数据库也没有，那么就会导致请求会各走一遍，有可能是遭遇攻击

解决方式 1做好接口鉴权，2布隆过滤器 3针对这样的查询，在缓存中写一个null进去

高可用问题

主从复制

持久化操作

1 RDB操作，在redis文件夹下面就有RDB文件，是redis中的数据持久化，

2 AOF操作， redis配置文件里可以设置多久执行一次

集群搭建 redis cluster

哨兵机制配合解决主从问题

单线程瓶颈问题

1 搭建集群

2 独写分离  主库写，从库读取

3 

数据淘汰策略

因为redis的惰性删除，所以内存中会有很多过期键，所以合适的数据淘汰策略就显得很有必要，一般都是从过期键里面进行筛选

基本数据类型

string

int 存数字的时候

raw 39字节较长的时候

enstr 小于39字节的时候

hash

ziplist 数组 数量小于512，长度小于64字节

list

双向链表

set

intset 所有都是整数，数量小于512

hash 其他

zset

ziplist 数组，数量小于128，单个小于64

跳表

消息队列

作用

1 解耦合，生产者和消费者之间解除耦合，通过消息队列中间件，多个生产者向同一个消息队列里写东西，消费者去拿东西

2 发布订阅模式，一个消息可以被多个消费者消费，如rabbitMq的topic

临时订阅，这种订阅只有在消费者启动并且运行的时候才存在。一旦消费者退出，相应的订阅以及尚未处理的消息就会丢失。

持久订阅，这种订阅会一直存在，除非主动去删除。消费者退出后，消息系统会继续维护该订阅，并且后续消息可以被继续处理。

3 削峰，通过中间件缓存功能，去实现该操作， 写入日志的时候，

4 异步调用， 发短信，邮件等

缺点

增加了系统的复杂性，需要高可用的消息队列来保证系统稳定

如果用异步的话，异常情况下的一致性问题

rabbitMQ

消息丢失

情况描述

1 生产者写消息的过程中，消息都没有到 rabbitmq，在网络传输过程中就丢了。或者消息到了 rabbitmq，但是人家内部出错了没保存下来

2 RabbitMQ 接收到消息之后先暂存在主机的内存里，结果消费者还没来得及消费，RabbitMQ自己挂掉了，就导致暂存在内存里的数据给搞丢了。

3 消费者消费到了这个消费，但是还没来得及处理，自己就挂掉了，RabbitMQ 以为这个消费者已经处理完了。

解决方案

1 事务机制或者confirm机制，去解决消息写入的方式

2 持久化到磁盘 创建queue的时候将其设置为持久化的，这样就可以保证 rabbitmq持久化queue的元数据，但是不会持久化queue里的数据发送消息的时候将 deliveryMode 设置为 2，将消息设置为持久化的，此时 rabbitmq就会将消息持久化到磁盘上去。必须同时设置 2 个持久化才行。持久化可以跟生产者那边的 confirm机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者 ack了 ，所以哪怕是在持久化到磁盘之前 ，rabbitmq挂了，数据丢了，生产者收不到 ack，你也可以自己重发。

消息重复消费

1 insert操作，主键机制 ，重复插入报错

2 幂等操作，update操作，重复操作不影响

3 消息增加ID，消费前先查表

消息持久化条件

声明队列必须设置持久化 durable 设置为 true.消息推送投递模式必须设置持久化，deliveryMode 设置为 2（持久）。消息已经到达持久化交换器。消息已经到达持久化队列。

缺点就是，必须持久化到磁盘，就牺牲了吞吐量，用的是磁盘而非内存存储

消息延迟策略

1 死信队列，建立一个死信队列来进行延时消息的收集（消息过期）

2 下载RabbitMQ-delayed-message-exchange插件去执行消息延迟发布，与headers有关

组件

1 队列 queue

存放消息的容器

2 消息交换器 exchange

fanoutExchange

绑定的所有队列中

directExchange

路由完全匹配

topicExchange

路由匹配规则

headerExchange

根据header进行匹配

集群

高可用

一台挂掉了，其他可以继续工作

更多的存储

集群可以承载更多的消息量。

角色

生产者

消息的创建者，负责创建和推送数据到消息服务器；

消息队列容器

就是 RabbitMQ 本身，用于扮演“快递”的角色，本身不生产消息，只是扮演“快递”的角色。

消费者

消息的接收方，用于处理数据和确认消息；

选型比较

吞吐量 rabbitMq<rocketMq<kafaka

延迟 rabbitmq<kafaka<rocketmq

高可用 rabbitmq基于主从 不如 racketmq和kafaka

消息的顺序处理，kafaka>rabbitmq

消息路由和过滤方面，rabbitmq>kafaka

消息时序 消息过期和延迟发送 rabbitmq>kafaka

灵活的路由规则 rabbitmq>kafaka  

应用

1 发送短信，邮件。 客户交易股票程交之后，发送短信通知

2 异步操作，档案收集，解除耦合

3 约券管理，类似于库存管理，有异步和削峰饿概念

4 档案管理系统， 档案下载的时候

中间件

nginx

进程模块

一个master和多个worker进程

日志模块

日志分级

连接模块

控制每个进程的连接数

http模块

全局http模块

upstream 模块

指定上游服务器地址

负载均衡

round-robin 算法

权重 weight

max_connect

max_fails和fail_timeout

hash算法模块

iphash

参数hash

一致性hash

对上游服务器进行keepalived

复用tcp连接

server服务器模块

内部负载均衡

epoll多路复用

连接请求进来后，分配到不同的accept，worker进程去处理，

读写请求依赖于连接请求，所以每个worker进程内部维护了自己的FD，并且去循环判断是否是自己可以处理的读写请求，不是则抛出，所以在一定程度上缓解了惊群效应

惊群效应通过加锁来实现，内部负载均衡，通过维护一个标识符，来判断当前worker进程建立的连接是否已经饱和，饱和就不去获得锁，也就不会建立新的连接了，

zookeeper

分布式服务协调管理服务

CAP理论

C一致性

P分区容错性

A可用性

BASE理论

基础部分

会话session

子主题

事件监听器 watcher

一次性

客户端串行执行

轻量级

崩溃恢复的原子广播协议ZAB

崩溃恢复，leader失效，重新选举

leader选举结束后，进行数据同步

四种同步类型，主要是根据leader服务器的事务方案id和learned的事务ID区间决定

分布式事务通知，二阶段提交

如何保证事务的顺序一致性

三个阶段

发现 (Discovery)

同步 (Synchronization)

广播 (Broadcast)

paxos算法，适用于分布式一致性状态系统，ZAB适合做主备系统

数据模型

znode节点

持久节点

临时节点

持久顺序节点

临时顺序节点

节点宕机

可以实现的内容

分布式锁

create 方式，利用一个目录只能创建一次，来实现分布式锁，本质while循环

watcher机制，利用watcher去监听节点，唤醒事件

发布订阅

推送，当服务端有信息修改，推送到注册中心时，会向所有监听的客户端推送信息

拉取，作为注册中心时，客户端第一次连接时会拉取关于服务端的信息，并建立监听，以及心跳

分布式队列

软负载均衡

命名服务

zookeeper用类似文件系统的全路径，来表示一个命名地址

Master 选举

集群主从同步

集群管理

节点上下线通知消费者

zookeeper集群

leader

事务请求的唯一调度和处理者，保证集群事务处理的顺序性

集群内部各服务的调度者

follower

处理客户端的非事务请求，转发事务请求给 Leader 服务器

参与事务请求 Proposal 的投票

选举leader节点

observer

3.0 版本以后引入的一个服务器角色，在不影响集群事务处理能力的基础上提升集群的非事务处理能力

不参与任何形式的投票

全限控制ACL

权限模式（Scheme）

授权对象

权限

增删改查 admin 五种全限

脑裂

过半选举机制就是为了解决脑裂问题

建立冗余的通信