发表于 | 分类于 ，

WAL即 Write Ahead Log，WAL的主要意思是说在将元数据的变更操作写入磁盘之前，先预先写入到一个log文件中。为什么要先写日志文件呢，我们一步一步的来探索。

基础数据了解

首先，我们需要了解一下几个数据。

从上图可以看出两点：

  1. 内存的读写速度比随机读写磁盘高出几个数量级。
  2. 磁盘顺序读写效率堪比内存

数据写入磁盘过程

那用户进程是怎么把数据写入磁盘的呢？我们来看下Redis之父Antires是怎么说的：

1: The client sends a write command to the database (data is in client’s memory).

2: The database receives the write (data is in server’s memory).

3: The database calls the system call that writes the data on disk (data is in the kernel’s buffer).

4: The operating system transfers the write buffer to the disk controller (data is in the disk cache).

5: The disk controller actually writes the data into a physical media (a magnetic disk, a Nand chip, …).

翻译如下：

  1. 客户端向数据库发送写命令。
  2. 数据库收到写命令。
  3. 数据库通过系统调用将数据写入内核缓冲区（page cache)。
  4. 操作系统将缓冲区数据传输至磁盘控制器，暂存在磁盘缓冲区。
  5. 磁盘控制器将数据精准的写入物理磁盘。

我们考虑如下异常情况：

异常处理

1、数据库挂了

如果只是数据库挂了，这时候其实操作系统是正常工作的，

只有当第3步完成之后，才能保证数据安全写入。因为剩下的都可以由操作系统来完成。

2、机器断电

机器断电之后，数据库、操作系统、磁盘均不能正常工作。只有完成这5步才算真正的写入磁盘。

WAL原理

  • 通过cache合并多条写操作为一条，减少IO次数
  • 日志顺序追加性能远高于数据随机写。

WAL的应用

MySQL WAL应用

MySQL通过redolog、undolog实现事务的原子性和持久化。

Hbase WAL应用

发表于 | 分类于 ，

可用性是服务的基石，当前使用面广的大部分开源软件均实现了高可用。

高可用的实现可以归纳为三点：

1、故障发现
2、数据同步
3、故障点切换

Mysql 高可用方案

MHA全称是Master High Availability，是一种一主多从的数据库高可用解决方案。他的特点是在保障高可用自切换的前提下，最大限度的保障主从数据的一致性。

MHA架构图如下：

一次完整MHA故障切换流程如下：

1. 保存故障的master节点的binlog日志;
2. Manager查找最新更新的slave节点；
3. 应用差异的relay log日志到其他的slave；
4. 在slave节点上应用从master保存的binlog日志；
5. 提升一个slave为新的master；
6. 使其他的slave连接新的master进行复制。

Redis 高可用方案

Redis-Sentinel 是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自动切换。

它的主要功能有以下几点

  • 不时地监控redis是否按照预期良好地运行;
  • 如果发现某个redis节点运行出现状况，能够通知另外一个进程(例如它的客户端);
  • 能够进行自动切换。当一个master节点不可用时，能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。

Redis-Sentinel架构图如下：

阅读全文 »

发表于 | 分类于

HTTP协议定义Web客户端如何从Web服务器请求Web页面，以及服务器如何把Web页面传送给客户端。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求报文，请求报文包含请求的方法、URL、协议版本、请求头部和请求数据。服务器以一个状态行作为响应，响应的内容包括协议的版本、成功或者错误代码、服务器信息、响应头部和响应数据。

HTTP Request

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：

请求行（request line）、请求头部（header）、空行和请求数据四个部分组成。

GET /562f25980001b1b106000338.jpg HTTP/1.1
Host    img.mukewang.com
User-Agent    Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36     (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Accept    image/webp,image/*,*/*;q=0.8
Referer    http://www.imooc.com/
Accept-Encoding    gzip, deflate, sdch
Accept-Language    zh-CN,zh;q=0.8

HTTP Response

一般情况下，服务器接收并处理客户端发过来的请求后会返回一个HTTP的响应消息。

HTTP响应也由四个部分组成，分别是：状态行、消息报头、空行和响应正文。

HTTP/1.1 200 OK
Date: Fri, 22 May 2009 06:07:21 GMT
Content-Type: text/html; charset=UTF-8

<html>
  <head></head>
  <body>
        <!--body goes here-->
  </body>
</html>

HTTP1.0 vs 1.1对比

功能 http1.0 http1.1
长连接 默认关闭，在http头加入”Connection: Keep-Alive”，才能启用 默认开启，加入”Connection: close “，才关闭
缓存 使用Expire头域来判断资源的fresh或stale；定义了Pragma:no-cache头域不使用缓存；If-Modified-Since头域使用的是绝对时间戳，精确到秒； 缓存对象的Age超过Expire时变为stale对象，cache不需要直接抛弃stale对象，而是与源服务器进行重新激活；引入了一个ETag头域用于重激活机制
节约带宽 不支持断点续传 请求消息中引入了range头域，它允许只请求资源的某个部分，支持断点续传
头部Host域 不支持 支持
消息传递 头域Content-MD5校验，不支持分块 引入Chunkedtransfer-coding，支持分块
错误码 16个 新增24个
阅读全文 »

发表于 | 分类于

易混淆错误码解析

常见错误码

We all come across website errors at some point, and every website out there has inevitably experienced their share of 404 and 500 status codes, which are shown when a URL is not found either due to their typo or a broken link (404), and when there is a general server error (500).

网站日常维护中，我们都不可避免的遇到过404和500状态码，
其中，404表示找不对对应的URL网页，500是通用服务器错误。

There are many other less well known status codes in the 400 and 500 range: Those HTTP status codes beginning with 4 are errors on the client side, and codes beginning with 5 are errors on the side of the website server.

在4xx-5xx的范围内，还有很多不常为人知道的状态：这些状态中4开头的表示客户端的错误，5开头的表示服务端的错误。

在这些错误码中，我们经常感到困惑的是499 vs 502 vs 504

499 vs 502 vs 504对比分析

错误码 错误内容 报错端 出现场景
499 服务端超时 客户端代理 服务端未在客户端设定的时间内响应结果，客户端主动断开连接。比如：服务器接口内SQL超时，导致接口超时。
502 网关错误 服务端代理 网站服务器返回不能识别的响应结果。比如：php-fpm未启动,或者php-fpm 挂了,或者PHP-fpm的max_childen设置太小，高并发场景下，连接耗尽。即问题出现时需要排查PHP-fpm的情况
504 网关超时 服务端代理 服务器未在反向代理设置的时间内响应。比如：nginx的fastcgi_read_timeout参数设置过小，后端服务响应慢时。即PHP-fpm没有在nginx规定的时间内返回数据。

参考资料

  1. The difference between a 502, 503 and 504 error

发表于 | 分类于

为什么考察系统设计类题目

系统设计题是高级工程师面试过程中必不可少的一类题目。这类题目经常能够真正考察面试者的真实综合实力，能够反映面试者的知识广度和深度。

这类题目往往面试官提供的信息非常少，需要面试者自己去思考系统功能、系统难点、设计方案，还要在设计过程中经受面试官的层层盘问和质疑。

然而，这和算法面试和程序面试不同的是，这类题目往往没有标准答案，主要看中的是你思考论述的过程，而不是你最后提出的解决方案（当然如果你提出的解决方案实在太挫……）。

也就是说，系统设计面试最重要的一点是“沟通”（communication）。

我们不会要求工程师一下子就开发出非常完美的功能。相反地，我们的工程师对于这些开放性问题有着充分的自主权。而且，我们的工作就是各自去为这些问题提出最佳的解决方案我们希望寻找的是那些我们可以完全信任的人。这样，他们自己就可以做出非常棒的方案，而不需要我们的监管。也就是说，我们需要的工程师，是那些可以管理一个很大项目，同时保持项目持续朝正确方向发展的人。这意味着，你必须可以高效地与身边的同时进行沟通。因为“闭门造车”在我们的大规模项目中是不可能的。

面试官考察点梳理

  • 沟通能力

    • 通过有效提问，了解业务功能和设计要点。

  • 技术能力

    • 全局设计能力和难题解决能力

  • 应变能力

    • 有效回答面试官的提问和质疑，通过不断的博弈，对方案进行改进和优化。

  • 知识水平

    • 需要掌握常用的开源软件，挑选最合适的来使用，并能有效对比各自的优缺点和使用场景。

答题套路

一、明确问题

拿到了问题之后，切记张口就来，我们只有一个大概的方向，即我们要做一个什么。但是并不清楚具体条件，而不同的的业务场景所需要的架构也是不一样的。

第一步我们需要先问几个问题：

  • 复述一下系统核心功能点和面试官对齐，看看自己的设想和面试官系统要求点是否一致（遇到自己没接触过过的系统时尤为必要）
  • 这个系统一天的请求量是多少？
  • 峰值QPS是多少

总结：

1、明确功能点
2、明确基本数据

二、模块划分

一个完整的系统往往包含多个组成部分，每个部分完成独立的工作，最后通过相互交互达成数据流转。

这一步我们要完成几点设计：

1、模块划分，每个模块需要完成的功能点，读写分离、动静分离、缓存读、异步写等等？
2、模块之间的数据交互，HTTP or RPC or MQ?

三、存储设计

这一步是涉及的关键，需要对常见存储工具都有一个清晰的认识，包括优缺点对比、适用场景。

存储硬件性能对比：

存储设备 吞吐量 响应时间
L1 Cache 0.5ns
L2 Cache 7ns
内存 800M/s 100ns
SSD 300M/s 0.1~0.2ms
机械硬盘 300M/s 10ms,其中寻道时间在9ms左右

常见性能数据

Nginx：能轻松的处理c100k问题，内存越大，能处理的并发量越高
Redis: https://redis.io/topics/benchmarks 表明，对于GET/SET来说，QPS 10-100k没啥大问题
MySQL: https://www.mysql.com/why-mysql/benchmarks/ 表明，对于只读，QPS 几百k没啥问题，对于写，MySQL 5.7 QPS 100k 几乎是上限, TPS基本上10K级别

存储软件对比分析：

存储软件 优点 缺点 适用场景
MySQL 支持事务，JOIN 大数据量扩容困难，字段频繁变更操作麻烦 事务需求，多表JOIN
Redis 高性能读写 内存昂贵，存储容量小 缓存
MongoDB 文档型，字段变更灵活，扩容简单 不支持事务、JOIN 字段不确定，变更频繁，性能和MySQL相差无几
Hbase 支持海量数据的存储 读写性能相对差一些 适用海量数据的存储分析，多版本，数据稀疏
ES 支持多维度查询，高可用 ES没有事务也不适合处理并行更改数据 适用于检索，全文检索

阅读全文 »

发表于 | 分类于

MySQL分库分表是大厂常见的技术方案。

为什么要做分库分表呢？

  1. 分库有利于服务隔离与解耦，方便单独扩容和故障恢复。
  2. 分表可以解决大表的运维难题，提高并发性能。

分库大家比较容易理解，一般随着业务粒度的划分进行。

而分表的形式和用途多种多样，同样达到的目的和效果也各不相同。

常见的解决大表问题的方案是水平分表。本文重点介绍水平分表的方案以及扩容方式。

常见水平分表方式

连续分片

根据特定字段(比如用户ID、订单时间)的范围，值在该区间的，划分到特定节点。
优点：集群扩容后，指定新的范围落在新节点即可，无需进行数据迁移。
缺点：如果按时间划分，数据热点分布不均(历史数冷当前数据热)，导致节点负荷不均。

ID取模分片

一致性Hash算法

Snowflake 分片

Snowflake 是 Twitter 开源的分布式 ID 生成算法，其结果为 long(64bit) 的数值。
其特性是各节点无需协调、按时间大致有序、且整个集群各节点单不重复。
该数值的默认组成如下(符号位之外的三部分允许个性化调整)：

Snowflake

阅读全文 »

发表于 | 分类于

我们都知道，Binlog是用来做主从同步的，redolog确保了事务的持久化特性。

那么MySQL到底是先写Binlog呢？还是先写的Redolog?

在不可靠的环境中怎么保证二者一致的呢？

我们带着这两个问题开始一探究竟。

MySQL体系结构

废话不多说，直接上图。（图片来源于网络）

  • Binlog是MySQL Server层的日志，一旦开启，任何存储引擎都会写Binlog日志
  • Redolog是存储引擎层的日志，即InnoDB的日志

从这个层次结构上来说，我们可以得出第一个问题的答案：
Binlog写先于Redolog

Binlog与Redolog一致性分析

注： 为了避免转述不准确，接下来的内容copy自网络，见参考资料。

MySQL没有开启Binary log的情况下？

首先看一下什么是CrashSafe？CrashSafe指MySQL服务器宕机重启后，能够保证：

– 所有已经提交的事务的数据仍然存在。

– 所有没有提交的事务的数据自动回滚。

Innodb通过Redo Log和Undo Log可以保证以上两点。为了保证严格的CrashSafe，必须要在每个事务提交的时候，将Redo Log写入硬件存储。这样做会牺牲一些性能，但是可靠性最好。为了平衡两者，InnoDB提供了一个innodb_flush_log_at_trx_commit系统变量，用户可以根据应用的需求自行调整。

阅读全文 »

发表于 | 分类于

大家应该都知道 ，MySQL单表过大，查询性能会直线下降，这时候就需要通过分库分表的方式来对单表划分多个小表，依此来提高性能。

那么问题来了，Mysql单表过大为什么查询性能会下降？MySQL单表过大的标准是多少？500W?2000W？

本文将来着这些问题来一探究竟。由于大部分业务生产环境的引擎使用的InnoDB，本文所有观点皆基于InnoDB引擎来阐述。

为了回答这些问题，我们先介绍一些基本概念和过程。

Mysql查询

Mysql SQL查询过程

  1. 客户端发送一条查询给服务器；

  2. 服务器先会检查查询缓存，如果命中了缓存，则立即返回存储在缓存中的结果。否则进入下一阶段；

  3. 服务器端进行SQL解析、预处理，再由优化器生成对应的执行计划；

  4. MySQL根据优化器生成的执行计划，调用存储引擎的API来执行查询；

  5. 将结果返回给客户端。

阅读全文 »

发表于 | 分类于

正在埋头写代码的兴头上，突然企微故障群不停地闪动，提示有人@。

A: xxx，你负责的服务不可用了，七层Nginx疯狂报警，赶快看一下日志。

我：挠头！7层是什么鬼？我命名在6层办公啊！

这时老大来了，丢下一句。

老大：‘你可以收拾东西回家了’。

我：卧槽！我真在6层办公。

。。。。。。

回家赶快google一下，哦，原来是7层协议的七层啊，不是楼层数啊。泪崩。。。

协议模型

OSI

TCP/IP模型

负载均衡

常见的负载均衡主要是四层负载均衡和七层负载均衡。

负载均衡器通常称为四层交换机或七层交换机。四层交换机主要分析IP层及TCP/UDP层，实现四层流量负载均衡。七层交换机除了支持四层负载均衡以外，还有分析应用层的信息，如HTTP协议URI或Cookie信息。

所谓四层就是基于IP+端口的负载均衡;

七层就是基于URL等应用层信息的负载均衡;

同理，还有基于MAC地址的二层负载均衡和基于IP地址的三层负载均衡。

阅读全文 »

发表于 | 分类于

TCP（传输控制协议）提供数据可靠传输，包括数据流传送、可靠性、有效流控、全双工操作和多路复用。通过面向连接、端到端和可靠的数据包发送。只支持1对1的通讯。

UDP（用户数据报协议）是一个简单的面向数据报的传输层协议。提供的是非面向连接的、不可靠的数据流传输。UDP不提供可靠性，也不提供报文到达确认、排序以及流量控制等功能。支持多对多的通讯。

另外，TCP建立连接需要三次握手，断开连接需要四次握手。

相信有网络基础的同学都已经掌握了，但对于那些参加面试的同学来说，掌握这些还不够。面试过程中常常遇到一些直击灵魂的问题？比如：

1
2
3
4
5
1. TCP为什么会是三次握手？二次或四次行不行？
2. SYN攻击的原理是什么？
3. Seq序号为什么要随机？
4. TCP如何保证数据有序的？
5. time_wait出现在什么时候？为什么要等待2ML后结束？

本文尝试按自己的理解来回答这些问题？

声明：本文不保证答案正确，仅代表个人理解，仅供交流参考。

先来看下正常的三次握手、四次挥手图解。

阅读全文 »