中间件
2021-02-22 16:07:29 65 举报AI智能生成
123
作者其他创作
大纲/内容
redis
spring-data-redis
redisTemplate<br>
五种数据类型操作
valueOperations, BoundValueOperations<br>
setoperations BoundSetOperations<br>
zsetoperations BoundListOperations<br>
hashoperations BoundSetOperations<br>
listoperations BoundHashOperations
事务操作封装
针对数据的序列化/反序列化
jdk pojo对象序列化
redisTemplate 字节方式序列化的方式存储
string 序列化存储
StringRedisTemplate 字符串的方式序列化存储
json 序列化存储
删除key，指定过期时间
发布/订阅
只能做简单的发布订阅，且发布者和订阅者必须实时连线，只支持1对N
缓存经典问题
缓存雪崩
缓存突然大面积失效，原因可能是集群环境节点出问题，过期时间问题，
解决方式1 集群，2热点数据永不过期，3过期时间随机，
缓存击穿
缓存中没有数据，请求直接打向数据库，数据库承受不住
解决方式 1 热点数据永不过期，2如果是一定要访问的，那么加锁执行，拿到锁的优先执行
缓存穿透
缓存没有，数据库也没有，那么就会导致请求会各走一遍，有可能是遭遇攻击
解决方式 1做好接口鉴权，2布隆过滤器 3针对这样的查询，在缓存中写一个null进去<br>
高可用问题
主从复制
持久化操作<br>
1 RDB操作，在redis文件夹下面就有RDB文件，是redis中的数据持久化，<br>
2 AOF操作， redis配置文件里可以设置多久执行一次
集群搭建 redis cluster
哨兵机制配合解决主从问题
单线程瓶颈问题
1 搭建集群
2 独写分离 主库写，从库读取
3
数据淘汰策略
因为redis的惰性删除，所以内存中会有很多过期键，所以合适的数据淘汰策略就显得很有必要，一般都是从过期键里面进行筛选
基本数据类型
string
int 存数字的时候<br>
raw 39字节较长的时候
enstr 小于39字节的时候
hash
ziplist 数组 数量小于512，长度小于64字节<br>
hash
list
ziplist 数组 数量小于512，长度小于64字节<br>
双向链表
set
intset 所有都是整数，数量小于512
hash 其他<br>
zset
ziplist 数组，数量小于128，单个小于64
跳表
消息队列
作用
1 解耦合，生产者和消费者之间解除耦合，通过消息队列中间件，多个生产者向同一个消息队列里写东西，消费者去拿东西
2 发布订阅模式，一个消息可以被多个消费者消费，如rabbitMq的topic
临时订阅，这种订阅只有在消费者启动并且运行的时候才存在。一旦消费者退出，相应的订阅以及尚未处理的消息就会丢失。
持久订阅，这种订阅会一直存在，除非主动去删除。消费者退出后，消息系统会继续维护该订阅，并且后续消息可以被继续处理。
3 削峰，通过中间件缓存功能，去实现该操作， 写入日志的时候，
4 异步调用， 发短信，邮件等
缺点
增加了系统的复杂性，需要高可用的消息队列来保证系统稳定
如果用异步的话，异常情况下的一致性问题
系统复杂性变高 可能发重复消息，导致插入重复数据；消息丢了；消息顺序乱了；系统 B,C,D 挂了，导致 MQ 消息积累，磁盘满了；
rabbitMQ
消息丢失
情况描述
1 生产者写消息的过程中，消息都没有到 rabbitmq，在网络传输过程中就丢了。或者消息到了 rabbitmq，但是人家内部出错了没保存下来
2 RabbitMQ 接收到消息之后先暂存在主机的内存里，结果消费者还没来得及消费，RabbitMQ自己挂掉了，就导致暂存在内存里的数据给搞丢了。
3 消费者消费到了这个消费，但是还没来得及处理，自己就挂掉了，RabbitMQ 以为这个消费者已经处理完了。
解决方案
1 事务机制或者confirm机制，去解决消息写入的方式
2 持久化到磁盘 创建queue的时候将其设置为持久化的，这样就可以保证 rabbitmq持久化queue的元数据，但是不会持久化queue里的数据发送消息的时候将 deliveryMode 设置为 2，将消息设置为持久化的，此时 rabbitmq就会将消息持久化到磁盘上去。必须同时设置 2 个持久化才行。持久化可以跟生产者那边的 confirm机制配合起来，只有消息被持久化到磁盘之后，才会通知生产者 ack了 ，所以哪怕是在持久化到磁盘之前 ，rabbitmq挂了，数据丢了，生产者收不到 ack，你也可以自己重发。<br>
3 关闭 autoAck,自己处理完了一条消息后，再发送 ack给 rabbitmq,如果此时还没处理完就宕机了，此时rabbitmq没收到你发的ack消息，然后 rabbitmq 就会将这条消息重新分配给其他的消费者去处理。
消息重复消费
1 insert操作，主键机制 ，重复插入报错
2 幂等操作，update操作，重复操作不影响
3 消息增加ID，消费前先查表
消息持久化条件
声明队列必须设置持久化 durable 设置为 true.<br>消息推送投递模式必须设置持久化，deliveryMode 设置为 2（持久）。<br>消息已经到达持久化交换器。<br>消息已经到达持久化队列。
缺点就是，必须持久化到磁盘，就牺牲了吞吐量，用的是磁盘而非内存存储
消息延迟策略
1 死信队列，建立一个死信队列来进行延时消息的收集（消息过期）
2 下载RabbitMQ-delayed-message-exchange插件去执行消息延迟发布，与headers有关
组件
1 队列 queue
存放消息的容器
2 消息交换器 exchange<br>
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<br>
进程模块<br>
一个master和多个worker进程
日志模块
日志分级
连接模块
控制每个进程的连接数
http模块
全局http模块
upstream 模块
指定上游服务器地址<br>
负载均衡
round-robin 算法<br>
权重 weight
max_connect<br>
max_fails和fail_timeout<br>
hash算法模块
iphash
参数hash
一致性hash
对上游服务器进行keepalived
复用tcp连接
server服务器模块
内部负载均衡
epoll多路复用
连接请求进来后，分配到不同的accept，worker进程去处理，
读写请求依赖于连接请求，所以每个worker进程内部维护了自己的FD，并且去循环判断是否是自己可以处理的读写请求，不是则抛出，所以在一定程度上缓解了惊群效应
惊群效应通过加锁来实现，内部负载均衡，通过维护一个标识符，来判断当前worker进程建立的连接是否已经饱和，饱和就不去获得锁，也就不会建立新的连接了，
zookeeper
分布式服务协调管理服务
CAP理论
C一致性
P分区容错性
A可用性
BASE理论
基础部分
会话session
子主题
事件监听器 watcher
一次性
客户端串行执行
轻量级<br>
崩溃恢复的原子广播协议ZAB<br>
崩溃恢复，leader失效，重新选举
leader选举结束后，进行数据同步
四种同步类型，主要是根据leader服务器的事务方案id和learned的事务ID区间决定
分布式事务通知，二阶段提交
如何保证事务的顺序一致性
三个阶段
发现 (Discovery)
同步 (Synchronization)<br>
广播 (Broadcast)<br>
paxos算法，适用于分布式一致性状态系统，ZAB适合做主备系统<br>
数据模型<br>
znode节点
持久节点
临时节点
持久顺序节点
临时顺序节点
节点宕机
可以实现的内容
分布式锁
create 方式，利用一个目录只能创建一次，来实现分布式锁，本质while循环
watcher机制，利用watcher去监听节点，唤醒事件
发布订阅
推送，当服务端有信息修改，推送到注册中心时，会向所有监听的客户端推送信息
拉取，作为注册中心时，客户端第一次连接时会拉取关于服务端的信息，并建立监听，以及心跳
分布式队列
软负载均衡<br>
命名服务
zookeeper用类似文件系统的全路径，来表示一个命名地址
Master 选举<br>
集群主从同步
集群管理<br>
节点上下线通知消费者
zookeeper集群
角色
leader
事务请求的唯一调度和处理者，保证集群事务处理的顺序性
集群内部各服务的调度者
follower
处理客户端的非事务请求，转发事务请求给 Leader 服务器
参与事务请求 Proposal 的投票<br>
选举leader节点
observer
3.0 版本以后引入的一个服务器角色，在不影响集群事务处理能力的基础上提<br><br>升集群的非事务处理能力
处理客户端的非事务请求，转发事务请求给 Leader 服务器
不参与任何形式的投票<br>
全限控制ACL
权限模式（Scheme）
授权对象
权限
增删改查 admin 五种全限
脑裂
过半选举机制就是为了解决脑裂问题
建立冗余的通信
0 条评论
下一页
