HTTP的状态码被分为了5大类，分别是：

1xx ： Hold on (等着)
2xx ： Here you go (执行完了，没毛病，拿着结果回去吧)
3xx ： Go away (你要的不在我这儿，去别处找)
4xx ： You fucked up (你丫出问题了)
5xx ： I fucked up (我特么出问题了)

状态码为客户端提供了一种理解事务处理结果的便捷方式（比解析字符串方便多了）

1xx （信息性状态码）：

一般来说，1xx类的状态码，发生在客户端和服务器交互过程中，两者对于某些情况做一定的约定，例如：

100 - Continue：说明收到了请求的初始部分，请客户端继续，发送了这个状态码之后，服务端在收到请求之后必须进行响应。

101 - Switching Protocols：说明服务器正在根据客户端的指定，将将协议切换成Update首部所列的协议

信息性状态码一般是在请求过程中，双方互相通知状态所使用，一般不会影响到本次请求的成功/失败。

报文的组成部分

HTTP报文 由起始行、首部、主体组成。

1、 起始行：

起始行是一个由行分隔的ASCII文本，每行都以一个由两个字符组成的行终止符作为结束，行终止符为 一个回车符 + 一个换行符，可以写作CRLF

2、 首部：

首部的格式与起始行相同

3、主体：

主体是一个可选的数据块，与起始行和首部不同的是，主题可以包含文本或二进制数据，也可以为空

报文的语法

所有的HTTP报文都可以分为两类：

1、请求报文：由客户端向web服务器请求一个动作

2、响应报文：向客户端返回请求的结果

例如，我们访问网址：http://jiayu.lu ，使用chrome浏览器，在地址栏中输入该网址并回车。此时按F12抓包的话，可以看见报文如下：

redis的事务和传统的关系型数据库不同，在关系型数据库中，用户首先向数据库发送一个BEGIN信号，然后执行各个相互一致的读写操作，最后，用户发送COMMIT来确认之前的操作，或者发送ROLLBACK来放弃之前的操作。

在redis中也有简单的方法可以处理一连串的读写操作，使用特殊命令MULTI为开始，然后传入一连串用户的操作，最后以EXEC结束，

但这种做法，实际上是在用户执行EXEC之前，客户端缓存保留所有命令，在EXEC之后一次性把所有命令发送到服务器执行，然后等待直到接收所有的命令回复为止，所以用户没办法根据读取到的数据来做决定是否rollback和commit。

但是，考虑这样一个情况：我们的商品a在redis里只剩2件，此时有两个客户都在购买它，分别是客户端A和客户端B，此时它们俩都执行命令：

> GET a
2
> MULTI
ok
> ..... do something
> SET a 1
ok
> EXEC
ok

如果此时两个客户端在同时购买了此商品，那么可能会导致此时a被更新为1，而不是0，而这明显是错误的。

如何解决这个问题？

基础背景：

URI:

uri(Uniform Resource Identifier) 是统一资源标识符，就像互联网上的地址一样，在世界范围内唯一标识并定位资源

URL:

url是uri最常见的形式，URL描述了一台特定服务器上某资源的特定位置。

大部分url都遵循一种标准格式：

1、第一部分被称为方案，说明了访问资源所使用的协议类型，例如我们常常看到的 http://、https://

2、第二部分给出了服务器的网络地址，例如 jiayu.lu，或者是127.0.0.1

3、其余部分指定了web服务器上的某个资源

目前，绝大部分uri都是url的形式

其实，url不仅可用在http协议，也可以通过ftp、smtp 等访问，它只是起一个标识资源位置的作用

URL的语法：

<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>

但其实我们最常见的是：

<scheme>://<host>:<port>/<path>?<query>

试想这样一个场景：

你有一张表,存储引擎为InnoDB，里面存储的数据量达到了上亿级别。

此时，因为数据量巨大，肯定不能在每次查询的时候都扫描全表。
就算是使用索引(B-Tree)，除非使用索引覆盖查询，否则数据库服务器需要根据查询的结果回表，查询所有符合条件的数据，
如果数据量巨大，会产生大量的随机IO，最终使得应用程序僵死。另外，这种数据量下，索引维护的代价也非常高。

分区表适用的场景？

分区表适用于数据量非常大，并且拥有某个特定字段可以据此将数据划分成几块的场景。

例如用户购买的商品记录表，可以依据购买时间，将全量记录划分为多个子分区。

那么有同学会问，为什么不直接用物理分表呢？

例如，有一张存储了3亿条商品数据的表goods，出于性能考虑，我们可能会将表拆分成300个子表，每张表存储100W条数据，此时，我们有了goods_0、goods_1….goods_299。

但这样做的问题是：开发者需要自行按照特殊条件，对于自身要操作的表做判断，然后自行改写sql去操作指定的物理子表，
这样的问题在于，将开发逻辑变得复杂化，并且代码变得”丑”了。
如果你使用了某些ORM框架，那么就更烦人了，你需要改写model定位自身table的逻辑。