序言

  MySQL 从 3.23 版本开始提供复制的功能。
  复制是指将主数据库的 DDL 和 DML 操作通过二进制日志传到复制服务器（也叫从库）上，然后在从库上对这些日志重新执行（也叫重做），从而使得从库和主库的数据保持同步。
  MySQL 支持一台主库同时向多台从库进行复制，从库同时也可以作为其他服务器的主库， 实现链状的复制。
  MySQL 复制的优点主要包括以下三个方面：

• 高可用：如果主库出现问题，可以快速切换到从库提供服务；
• 负载均衡：读写分离使得可以在从库上执行查询操作，降低主库的访问压力；
• 数据安全：可以在从库上执行备份，以避免备份期间影响主库的服务

序言

  从前文我们知道，在事务运行过程中，数据库设置的隔离级别不同，解决的并发问题也不同。
  那么思考一个问题：这些隔离级别在内部到底是如何解决并发问题的呢？
  在数据库系统中，是通过 MVCC 和锁机制来解决该问题的。

  那么，下面来详细了解下它们吧！

前言

  随着技术的不断发展，后端领域慢慢摒弃传统的单体架构，转而开始流行微服务架构模式。
  微服务中将服务按业务拆分的理念确实不错，但福祸相依，单体架构转换为微服务架构的过程中，不可避免的会遇到一些问题。

  我们首先遇到的一个问题就是——如何去管理这些拆分出来的服务？

  假设现在一个系统存在 A、B、C 三个应用，每个应用部署三份，则现在存在了 A1、A2、A3、B1、B2、B3、C1、C2、C3 共九个应用。

  这些应用并非各为孤岛，而是彼此联系，需要相互调用，比如 A –> B –> C（ A 应用需要调用 B，B 调用 C）。
  在调用的时间轴中，不得不考虑以下问题：

• A 应当去调用谁，哪个 B？B 调用 C 同理，人为手动的去管理调用关系吗？这明显不科学
• A 调用 B 的时候，应当选择 B1、B2，还是 B3？不可能一直调用一个吧？那么应当采取什么路由策略？
• 若调用后某个应用宕机了，再次调用时必然失败，此时是否只允许调用可用的呢？

  经以上分析，我们发现——微服务中迫切需要一个组件来管理大量微服务，这个组件一般被称为注册中心。

  除此之外，我们还发现多应用中，冗余了大量重复的的配置属性，比如说：

• 数据库的连接信息
• 定时任务的启动信息
• 某些特定功能的开关属性
• ……

  这些属性部分重复且应用一经发布若想二次修改，则必须重启应用才能生效，另外，不同环境的各种属性配置又不一样。
  那么，思考这些问题：

• 类似 Java 的继承特性，重复的属性能否抽离共用？
• 配置热部署，属性是否支持修改不重启即可生效？
• 能否支持多环境，甚至异地？

  经以上分析，我们发现——微服务中迫切需要一个组件来管理大量微服务的配置属性，这个组件一般被称为配置中心。

  那么，市面上有没有一个框架，既可当成注册中心，又可充当配置中心，两全其美的解决上面我们遇到的问题呢？
  当然是有滴啦，Nacos 就可以充当这两个角色，并且其更加强大。

简介

  RabbitMQ 是采用 Erlang 语言实现 AMQP (Advanced Message Queuing Protocol ，高级消息队列协议）的消息中间件， 它最初起源于金融系统， 用于在分布式系统中存储转发消息。

前言

  正常来讲，Elasticsearch 的集群状态status属性应该显示为green，但在 ES 的使用过程中，我们经常会遇到这么一个问题——集群状态显示为yellow或red。