HTTP 报文

报文的组成部分

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

1、 起始行:

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

2、 首部:

首部的格式与起始行相同

3、主体:

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


报文的语法

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

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

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

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

redis 事务

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

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

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

但也正是因为它一次性传输所有命令的方式,可以将N条命令造成的N次网络往返,浓缩到1次网络往返,所以性能得到了提高

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

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

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

如何解决这个问题?

Url 初步介绍

基础背景:

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>

Mysql分区表 介绍和使用

试想这样一个场景:

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

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

分区表适用的场景?

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

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

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

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

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

Redis ZipMap 数据结构和源码剖析

在redis中,使用 hashtable 实现了 set、sorted set、hash 结构。而单纯的 hashtable ,因为是一次分配一大块内存,所以在存储少量数据时会存在空间利用率很低的问题。

redis 是内存数据库,而内存是昂贵的,所以需要尽量避免内存的浪费,所以有了 zipmap 结构。

zipmap?

我们通过 what、why、how 来对 zipmap 进行全面的认识

what?(它是什么)

ZipMap 实质上就是一个特殊格式的字符串。

why?(为什么要用它)

因为redis是个内存数据库,要尽量避免内存浪费

how?(它是怎么实现的)

zipmap 是用连续内存保存 key-value 对的结构,查询时是依次遍列每个 key-value 对,直到查到为止。其存储结构如下所示:
zipmap 结构图示