序言

  从前文我们知道，在事务运行过程中，数据库设置的隔离级别不同，解决的并发问题也不同。
  那么思考一个问题：这些隔离级别在内部到底是如何解决并发问题的呢？
  在数据库系统中，是通过 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。

前言

  在互联网中，数据就是金钱，为了防止出现数据丢失无法找回的意外，通常都会对数据库做定期备份动作。
  那么，MySQL 如何实现此目的呢？

  下面，我们就使用 MySQL 自带的 mysqldump 命令结合 Linux 的 crontab 工具来定时全量备份数据！

序言

  通过对此书的学习，能够让我们获取以下问题的答案：

• 为什么使用异步编程？
• 在 Java 中如何编写异步编程的代码？
• 在 Java 中如何编写对异步编程的结果进行特殊处理的代码？

序言

  分片是 ES 中的一个重要概念，围绕着分片，我们会有很多疑问：

• 文档是什么？
• 分片是什么？
• 文档与分片关系如何？
• 分片的作用？
• 文档存储在哪个分片？
• 主副分片间如何交互？

  本文将通过一些说明来解答这些疑问。

序言

  人非圣贤，孰能无过？
  对程序而言，同样如此，即使一个产品经历了一系列的开发测试工作，在此过程中又遇到并解决了成百上千个 Bug，最终交付给客户并正式上线了，后期还是可能会出现一些问题。
  这些问题的产生，可能是客户进行了不符合逻辑的异常操作引起的，也可能是程序代码原先判断逻辑本就存在问题，还有可能是某个应用或服务器资源（CPU、内存、磁盘、网络）出现异常了。但不管怎样，是问题就应当给客户解决，不然客户不满意了，公司的企业形象降低了，若后期还有合作，说不定就泡汤了呢！合作泡汤了，说不定整个业务部门就给你优化掉，程序员就没班上了呢！！！
  作为程序员，为了防止被优化的意外发生，还是老老实实的帮客户解决问题吧！
  那么，怎么去解决问题呢？
  作为一个程序员，接到一个产品问题，想的应该不是解决，而是分析问题的类型，待分析出问题的类型后，才去解决问题。
  那么，问题大概又可以分为哪几种类型呢？
  笔者认为，其大致可以分为以下三种：

• ① 理解问题：做的需求不符合客户的预期效果，客户不买帐，那么，互相扯皮或者重新做~
• ② 代码问题：程序存在 Bug，这又进一步可以分为三种：
  • 前端 Bug：前端程序问题，页面设计不合理或与后端对接不正确
  • 后端 Bug：后端程有问题，逻辑错误或重大 Bug 导致应用的宕机，那么让后端同学修复
  • 运维 Bug：服务器配置问题，让实施同学（通常被后端同学替代…）解决
• ③ 服务器问题：CPU、内存、磁盘，网络资源引起的问题

  现在，我们得到了一个结论——问题的存在形式是多种多样的，因此我们遇到问题不能局限在某一块思考（后端开发不能碰到问题就想的是看日志，得明确是后端问题才去看日志），因为不同的问题解决方案也不一样。

  由于只有在大致分析出问题的类型后，才能尝试去解决问题：

• 针对问题 ①，我们有时可以甩锅给产品同学——你的需求不对呀，我肯定做错呀（叉腰：理直气壮），当然有时也需要自己接锅（自己理解不到位）
• 针对问题 ②，通常需要看线上日志来定位问题的产生原因，尝试复现 Bug
• 针对问题 ③，需要去看服务器某段运行时间里资源情况（注意哦，是观测服务器在某段运行时间里资源情况，因为线上出问题了，肯定是之前某个时间点出的问题，我们仅仅观察出错后的资源占比情况不一定能找出问题所在）

  那么，又该如何去观察服务器在某段运行时间里的资源情况是怎样的呢？
  这个时候，就需要布置一套监控系统来辅助我们程序员观察分析了。