[toc]

redo log

​ 在innoDB的存储引擎中，事务日志通过 redolog 和innoDB存储引擎的日志缓冲(InnoDB Log Buffer)实现。

​ 事务开启时，事务中的操作，都会先写入存储引擎的日志缓冲中，在事务提交之前，这些缓冲的日志都需要提前刷新到磁盘上持久化，这就是Write-Ahead Logging。当事务提交之后，在Buffer Pool中映射的数据文件才会慢慢刷新到磁盘。此时如果数据库崩溃或者宕机，那么当系统重启进行恢复时，就可以根据redo log中记录的日志，把数据库恢复到崩溃前的一个状态。未完成的事务，可以继续提交，也可以选择回滚，这基于恢复的策略而定。

​ 在系统启动的时候，就已经为redo log分配了一块连续的存储空间,以顺序追加的方式记录redo Log，通过顺序IO来改善性能。所有的事务共享redo log的存储空间，它们的redo Log按语句的执行顺序，依次交替的记录在一起。如下一个简单示例：

• 记录1：<trx1, insert…>
• 记录2：<trx2, delete…>
• 记录3：<trx3, update…>
• 记录4：<trx1, update…>
• 记录5：<trx3, insert…>

[toc]

Update & Delete语句加锁

1）主键索引（查询命中）

1

UPDATE students SET score = 100 WHERE id = 15; // id主键

RC、RR都是对聚簇索引加X锁。

[toc]

前言

一条SQL语句(select)在mysql里面的执行过程如下：

  RPC框架的核心目标是解决分布式系统中服务之间的调用问题。

RPC框架三个核心角色

  1)服务提供者（Server）对外提供后台服务，将自己的服务信息，注册到注册中心

  2)注册中心（Registry）用于服务端注册远程服务以及客户端发现服务。

  3)服务消费者（Client） 从注册中心获取远程服务的注册信息，然后进行远程过程调用。

RPC远程调用过程

  1）服务调用方（client）调用以本地调用方式调用服务；
  2）client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；在Java里就是序列化的过程；
  3）client stub找到服务地址，并将消息通过网络发送到服务端；
  4）server stub收到消息后进行解码,在Java里就是反序列化的过程；
  5）server stub根据解码结果调用本地的服务；
  6）本地服务执行处理逻辑；
  7）本地服务将结果返回给server stub；
  8）server stub将返回结果打包成消息，Java里的序列化；
  9）server stub将打包后的消息通过网络并发送至消费方；
  10）client stub接收到消息，并进行解码, Java里的反序列化；
  11）服务调用方（client）得到最终结果。

  RPC框架的目标就是要2~10这些步骤都封装起来。

[toc]
首先介绍下分布式共识算法。分布式共识算法是指：多个参与者 针对 某一件事 达成完全 一致 ：一件事，一个结论；已达成一致的结论，不可推翻。

目前分布式共识算法有如下：

• Paxos：被认为是分布式共识算法的根本，其他都是其变种，但是 Paxos 论文中只给出了单个提案的过程，并没有给出复制状态机中需要的 multi-paxos 的相关细节的描述，实现 Paxos 具有很高的工程复杂度（如多点可写，允许日志空洞等）。
• Zab：被应用在 Zookeeper 中，业界使用广泛，但没有抽象成通用的 library。
• Raft：以容易理解著称，业界也涌现出很多 Raft 实现，比如大名鼎鼎的 etcd, braft, tikv 等。

[toc]

1. 什么是SLA（服务等级协议）？

SLA（Service-Level Agreement）服务等级协议，是指系统服务提供者（Provider）对客户（Customer）的一个可量化的服务承诺，常见于大型分布式系统中，用于衡量系统服务是否稳定健康的常见方法。

2. SLA（服务等级协议）常用的衡量指标有哪些？

SLA是一种服务承诺，因此指标具备多样性, 业界主流常用指标包含：可用性、准确性、系统容量和延迟。

[toc]

一、 背景

实际系统中有很多操作，不管做多少次，都应该产生一样的效果或返回一样的结果。比如完成一个订单流程时经常遇到下面的场景：

1. 一个订单创建接口，第一次调用超时了，然后调用方重试了一次
2. 在订单创建时，需要去扣减库存，这时接口发生了超时，调用方重试了一次
3. 当这笔订单开始支付，在支付请求发出之后，在服务端发生了扣钱操作，接口响应超时了，调用方重试了一次
4. 一个订单状态更新接口，调用方连续发送了两个消息，一个是已创建，一个是已付款。但是先接收到已付款，然后又接收到了已创建
5. 在支付完成订单之后，需要发送一条短信，当一台机器接收到短信发送的消息之后，处理较慢。消息中间件又把消息投递给另外一台机器处理。

为了解决以上问题，就需要保证接口的幂等性。

[toc]
如果在公司里落地生产环境用分布式锁的时候，一定是会用开源类库的，比如Redis分布式锁，一般就是用Redisson框架就好了，非常的简便易用。感兴趣可以去Redisson官网看看如何在项目中引入Redisson的依赖，然后基于Redis实现分布式锁的加锁与释放锁。

一段简单的使用代码片段，先直观的感受一下：

是不是感觉简单的不行！此外，还支持Redis单实例、Redis哨兵、Redis Cluster、redis master-slave等各种部署架构，都可以完美实现。

  什么是微服务架构，得先知道什么系统架构设计?
  系统架构设计描述了在应用系统的内部，如何根据业务、技术、组织、灵活性、可扩展性以及可维护性等多种因素，将应用系统划分成不同的部分，并使这些部分彼此之间相互分工、相互协作，从而为用户提供某种特定的价值的方式。

单体架构

优点：
  1、易于开发： 开发方式简单，IDE 支持好，方便运行和调试。
  2、易于测试： 所有功能运行在一个进程中，一旦进程启动，便可以进行系统测试。
  3、易于部署： 只需要将打好的一个软件包发布到服务器即可。
  4、易于水平伸缩： 只需要创建一个服务器节点，配置好运行时环境，再将软件包发布到新服务器节点即可运行程序（当然也需要采取分发策略保证请求能有效地分发到新节点）。

缺点：
  1、维护成本大： 当应用程序的功能越来越多、团队越来越大时，沟通成本、管理成本显著增加。当出现 bug 时，可能引起 bug 的原因组合越来越多，导致分析、定位和修复的成本增加；并且在对全局功能缺乏深度理解的情况下，容易在修复 bug 时引入新的 bug。
  2、持续交付周期长： 构建和部署时间会随着功能的增多而增加，任何细微的修改都会触发部署流水线。
  3、新人培养周期长： 新成员了解背景、熟悉业务和配置环境的时间越来越长。
  4、技术选型成本高： 单块架构倾向于采用统一的技术平台或方案来解决所有问题，如果后续想引入新的技术或框架，成本和风险都很大。
  5、可扩展性差： 随着功能的增加，垂直扩展的成本将会越来越大；而对于水平扩展而言，因为所有代码都运行在同一个进程，没办法做到针对应用程序的部分功能做独立的扩展。

服务熔断

  在微服务架构中，微服务之间的数据交互通过远程调用完成，微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，此时如果链路上某个微服务的调用响应时间过长或者不可用，那么对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，导致“雪崩效应”。
  服务熔断是应对雪崩效应的一种微服务链路保护机制。例如在高压电路中，如果某个地方的电压过高，熔断器就会熔断，对电路进行保护。同样，在微服务架构中，熔断机制也是起着类似的作用。当调用链路的某个微服务不可用或者响应时间太长时，会进行服务熔断，不再有该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。

  在Spring Cloud框架里，熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败，就会启动熔断机制。
  服务熔断解决如下问题： 1. 当所依赖的对象不稳定时，能够起到快速失败的目的；2. 快速失败后，能够根据一定的算法动态试探所依赖对象是否恢复。