中间件
2021-02-22 16:07:29 64 举报AI智能生成
123
作者其他创作
大纲/内容
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 五种全限
脑裂
过半选举机制就是为了解决脑裂问题
建立冗余的通信
0 条评论
回复 删除
下一页
