Broker 端参数 log.dirs：Broker 需要使用的若干个文件目录路径，必须指定；最好不同路径挂载到不同的物理磁盘，提升读写性能且能能够实现故障转移 log.dir：单个路径 zookeeper.connect：zookee

多线程问题单个主线程处理网络请求的速度跟不上底层网络硬件的速度。 优化多个 IO 线程并行处理网络操作，可以提升实例的整体处理性能。 使用单线程执行命令操作，就不用为了保证 Lua 脚本、事务的原子性，额外开发多线程互斥机制了。 具体流程1

需求分析 消息保序：消费者需要按照生产者发送消息的顺序来处理消息 处理重复的消息：消费者避免多次处理重复的消息 保证消息可靠性：消费者重启后，可以重新读取消息再次进行处理 基于List LPUSH 把要发送的消息依次写入 Lis

事务实现基本命令 MULTI 显式地表示一个事务的开启，把这些命令暂存到一个命令队列中 EXEC 实际执行命令队列中的所有命令 DISCARD 主动放弃事务执行，把暂存的命令队列清空（起不到回滚的效果） WATCH 在事务执

为了保证并发访问的正确性，Redis 提供了两种方法，分别是加锁和原子操作。 原子操作 单命令操作（INCR/DECR）； 把多个操作写到一个 Lua 脚本中，以原子性方式执行单个 Lua 脚本 分布式锁 分布式锁的加锁和释放锁的过程，涉

redis缓存使用 应用读取数据时，需要先读取 Redis； 发生缓存缺失时，需要从数据库读取数据并更新缓存。 Redis为旁路缓存，因为读取缓存、读取数据库和更新缓存的操作都需要在应用程序中来完成。 缓存分类 只读缓存：加速读请求。

消息丢失场景消息从生产者写入到消息队列的过程问题原因：网络抖动 解决办法： 事务在生产者发送消息之前，通过channel.txSelect开启一个事务，接着发送消息， 如果消息投递失败，进行事务回滚channel.txRollback，然

场景 可靠性投递机制：mq收到生产者消息，mq在返回confirm的时候网络出现闪断，导致broker未收到应答，导致发送两次。 MQ Broker服务与消费端传输消息的过程中出现网络抖动。 消费端故障、异常。 解决方案可靠性投递解决对每

集群概述 集群节点类型 磁盘节点：运行时状态信息（集群、队列、绑定虚拟主机、用户、策略等）存储在内存和磁盘中。集群至少有一个磁盘节点。关闭集群后，重启时需要按照一定顺序启动。 内存节点：运行时状态信息（集群、队列、绑定虚拟主机、用户、策略等

消费方法Basic.Get 每次接收消息必须发送一次请求 有消息可用，RabbitMQ返回Basic.GetOk以及消息 无消息可用，RabbitMQ返回Basic.GetEmpty 应用程序需要评估RPC响应以及是否接收到消息。 示例

direct交换器 特点 投递的消息有一个或者多个确定的目标。 检查字符串是否相等，不允许使用模式匹配。 绑定相同路由键的队列都能收到该路由键对应的消息。 适用于RPC消息通信模式下的路由应答消息 示例代码：Direct交换器 impo

可靠投递 mandatory当交换器无法路由消息，RabbitMQ将回发Basic.Return消息到发布者，同时回发完整消息。Basic.Return是异步的，在消息发布后的任何时候都可能发生。在rabbitpy库中，客户端自动接收Bas