docker内容整理

本文介绍: 目前为止使用到的应用。

目前为止使用到的应用

mysql 相关

相关链接：mysql主从、canal、nexus

配置 主从

主从配置原理：

MySQL master 将数据变更写入二进制日志( bin a ry log, 其中记录叫做二进制日志事件 bin a ry log events，可以通过 show binlog events 进行查看)；
MySQL slave 将 master 的 bin a ry log events 拷贝到它的中继日志(rel a y log)；
MySQL slave 重放 rel a y log 中事件，将数据变更反映它自己的数据；

canal【配合rabbitmq 使用】

描述：

canal 翻译为管道，主要用途是基于 MySQL 数据库的增量日志 Bin lo g 解析，提供增量数据订阅和消费。

基于日志增量订阅和消费的业务包括：

工作原理：

canal 模拟 MySQL slave 的交互协议，伪装自己为 MySQL slave ，向 MySQL master 发送 dump 协议；
MySQL m a ste r 收到 dump 请求，开始推送 bin a ry lo g 给 slave (即 canal )；
c anal 解析 bin a ry lo g 对象(原始为 byte 流)；

私服nexus

描述：

使用Ne xus 搭建私服有很多好处，其中最主要的原因是可以控制构件的访问和部署。如果没有Ne xus私服，我们所需的所有构件都需要通过Mav en的中央仓库和第三方的Mav en仓库下载到本地，而一个团队中的所有人都重复的从Mav en仓库下载构件无疑加大了仓库的负载和浪费了外网带宽，如果网速慢的话，还会影响项目的进程。而使用Ne xus 搭建私服后，只需要在私服上进行一次下载，就可以在整个团队中使用，大大提高了效率。

此外，Ne xus还具有很多其他优点，例如占用内存小、具有基于Ex tJs得操作界面、使用基于Res t let的完全REST API支持代理仓库、宿主仓库和仓库组、基于文件系统，不需要依赖数据库、支持仓库管理、支持构件搜索、支持在界面上上传构件等等。

redis相关

相关链接：redis主从、哨兵、redis插件

redis 主从

主从复制的作用

读写分离：主节点写，从节点读，提高服务器的读写负载能力
数据冗余︰主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复︰当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复 ; 实际上是一种服务的冗余。
负载均衡︰在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redi s 数据时应用连接主节点，读Redi s 数据时应用连接从节点），分担服务器负载 ; 尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redi s 服务器的并发量。
高可用（集群）基石︰除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

redis 哨兵

哨兵的作用

在主从模式下，主从复制机制使得slave 成为与ma ster完全一致的副本，一旦ma ster宕机，我们可以选择一个正常的slave 成为新的主节点，实现手动的故障恢复。

哨兵专注于对Redis实例（主节点、从节点）运行状态的监控，并能够在主节点发生故障时通过一系列的机制实现选主及主从切换，实现故障转移，确保整个Redis系统的可用性。

插件

bloom filter（布隆 过滤器）

To ken-Buc k e t（令牌桶）

rabbitmq相关

相关链接：docker搭建rabbitmq、配置延迟队列插件

消息队列的作用：消峰、解耦、异步

延迟 队列：

延迟队列是一种特殊的队列，用于延迟消息的投递。在Rab bitMQ中，延迟队列不是一个内置的功能，但可以通过插件（如rabbitmq–delay e d–message–exchange）或者使用TTL（Time-To-Li ve）和死信交换机（DLX）的组合来实现。当消息发送到延迟队列时，它不会立即被消费者接收，而是在队列中等待一定的时间（延迟时间），时间到了之后，消息才会被发送到另一个队列，然后被消费者处理。

应用 场景

定时任务：可以将需要在未来某个时间点执行的任务放入延迟队列，当时间到达时，任务被发送到正常队列并执行。
消息重试：在处理消息时，如果遇到暂时性的错误（如网络问题或服务不可用），可以将消息重新发送到延迟队列，等待一段时间后再次尝试处理。
订单超时处理：例如，电商平台中未支付订单的超时关闭，可以在订单创建时发送一个延迟消息，如果用户在规定时间内未支付，消息到期后触发订单关闭流程。
提醒通知：比如预约提醒、会议开始前的通知等，可以在预定时间前将提醒消息发送到延迟队列，到时间后自动通知用户。

死信队列：

死信队列用于存放无法正常投递的消息，这些消息可能因为以下几种情况被投递到死信队列：

消息被拒绝（basic.rejec t 或 basic.nack）并且设置了re queue 参数为false。

消息过期（TTL过期）。

队列达到最大长度。

在Rab bitMQ中，可以通过设置队列的x-dead-letter-exchange和x-dead-letter-routing-key参数来指定死信交换机和路由键，从而将死信消息重定向到特定的死信队列。

应用 场景

消息审计和排错：当消息无法被正常消费时，将其发送到死信队列，开发人员可以从死信队列中检查和分析这些消息，找出问题原因。
消息保护：避免因为消费者的错误处理导致消息丢失，通过死信队列可以保留这些消息，进行后续的处理。
流量削峰：当系统处理能力达到上限时，可以将超出能力的消息暂时存放在死信队列中，等系统负载降低后再进行处理。
消息重试策略：结合延迟队列，可以实现消息的延迟重试机制。当消息处理失败后，先发送到死信队列，然后再根据需要将其发送到延迟队列等待重试。

延迟队列和死信队列可以单独使用，也可以结合起来使用，以满足复杂的业务需求。例如，可以将消息从延迟队列发送到正常队列，如果消费失败，则进入死信队列，之后可以从死信队列中取出消息进行分析或者再次发送到延迟队列进行重试。

nginx

docker搭建nginx实现负载均衡

gitlab

docker–compose

简单使用

version: '2'
networks:
  wn_docker_net:
    external: true
services:
  replication-01:
    build: .
    image: replication
    container_name: appointment01
    ports:
      - "15350:15350"
    networks:
      wn_docker_net:
        ipv4_address: 172.18.12.110