第 10 页的文章列表

这篇文章是我在查找如何对redis中的值做原子操作时的一系列笔记，虽然最初的目的只是研究有哪些方式可以实现事务(transaction)操作，但是后来的延伸很多，所以我认为有必要做一些笔记防止忘记。

1.redis中的事务

redis中的事务其实并不满足数据库事务的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离型（Isolation）、持久性（Durability），简称ACID。redis只能在一致性和隔离性上提供保证，而原子性和持久性是无法保证的。因为redis的事务操作如果中断，无法回滚，满足不了原子性，并且redis的持久化策略有很多中，比如在纯内存模式下是无法持久化数据库更改的，满足不了持久性。 所以下面针对与redis事务的讨论都是有局限性的。仅仅是指对redis数据进行操作时，不会受到其他客户端的干扰。举例来说：客户端A读取keyA，修改keyA中间，不会受到客户端B的影响。

    //客户端A执行以下代码
    //获取user1的性别，如果性别是男，头像设置为男性角色
    //否则头像设置为女性角色
    $gender = $redis->get('user1_gender');
    if($gender === 'male'){
        $redis->set('user1_photo','male.png');
    }else{
        $redis->set('user1_photo','female.png');
    }

    //客户端B执行以下代码
    //更改user1的性别，如果是男则改为女，如果是女则改为男
    //并根据性别设置头像
    $gender = $redis->get('user1_gender');
    if($gender === 'male'){
        $redis->set('user1_gender','female');
        $redis->set('user1_photo','female.png');
    }else{
        $redis->set('user1_gender','male');
        $redis->set('user1_photo','male.png');
    }

如果客户端A、B同时只有一个执行，那么性别和头像一定是对应的。但是A、B同时执行，并且执行顺序如下: 那么执行结果就是user1性别为女，但头像为男性角色。 所以针对于这种情况，我们需要一定的措施去预防。 redis的事务实现方式有多种。据我所知有三种方式：

• 1.MULTI/EXEC
• 2.WATCH/UNWATCH
• 3.lua脚本

1.1 MULTI/EXEC

MULTI/EXEC是成对出现的指令。大家都知道，redis执行指令是单线程的，也就是说所有指令都处于一个队列，一个一个执行。MULTI/EXEC可以保证所有的指令都会被同时放松到redis中，中间不会掺杂来自其他客户端的指令。 但是这个针对于上述情况并不适用。因为我们需要在GET到数据之后，才能做下面的更新操作。

1.2 WATCH/UNWATCH

在redis中我们可以使用watch来监视一个值。

redis> WATCH name
OK

redis> MULTI
OK

redis> SET name peter
QUEUED

redis> EXEC
(nil)

比如这段代码，在我们WATCH name后，如果另外一个客户端修改了name的值，那么这个客户端再次修改name则无法成功。这其实就是乐观锁的一种实现。它保证了代码的执行结果不会错乱。用一开始的例子来说，就是不会出现性别和头像不对应的情况。 1.3 lua脚本 redis中可以执行lua脚本来完成事务操作。lua脚本和MULTI/EXEC很像，也就是说在lua脚本执行的过程中，redis是不执行其他客户端的指令的。 但是lua脚本的不同之处在于，你可以使用GET操作来获取数据并判断，再执行后来的操作。

2.在redis操作中使用锁

在多线程环境中，为了防止资源出现race condition，需要借助锁来互斥的访问资源。在这里也是一样的，user1_gender就是我们要互斥访问的资源。 还是上述那个例子，如果我们使用悲观锁，只有获得锁的客户端才能读取和修改user1的的值，也可以很好的解决这个问题。 伪代码如下：

$can_lock = lock('user1_gender'); //得到锁
if($can_lock){
    do_something();
    $release_lock('user1_gender');  //释放锁
}

不同于多线程环境下的是，我们这里的锁的范围是针对于不同的客户端。因此没法使用基于系统的、或者基于语言的锁，而是得使用分布式的锁。这样的分布式锁我们同样可以借助于redis来实现。 整个分布式锁的实现可以概括为以下几个步骤：

• 1. 获得锁。得到要锁的资源的唯一hash：lockname,以及一个随机字符串：identifier，设置expire：20s,这个expire就是锁的有效期，在有效期后锁会自动释放，防止出现死锁。在redis中使用setnx(lockname,identifier,expire)。这句代码的意思是:如果redis中不存在lockname，则存入lockname，值为identifier，过期时间是expire。
• 2. 第一步我们就得到了一个锁，这一步我们开始执行获得锁之后的代码
• 3. 释放锁。我们根据lockname来从redis中查找。如果get(lockname) identifier，则表示我们仍然持有这把锁，使用delete(lockname)来释放锁。如果不等于，说明我们已经不持有这把锁了，则什么也不做。

那么lock函数可以用以下代码来描述:

function lock($lockname,$identifier,$expire = 20){
    $acquire_timeout = 10;      //花费10秒去获得锁，否则就放弃
    $end = time() + $acquire_timeout
    while (time() < $end){
        $can_lock = $redis->setnx($lockname,$identifier,$expire);
        if($can_lock){
            return true;
        }
        sleep(0.1);
    }

    return false;
}

    function release_lock($lockname,$identifier){
        $redis->watch($lockname);
        try{
            if($redis->get($lockname) === $identifier){
                //锁仍然持有，释放锁
                $redis->delete($lockname);
                return true;
            }

            $redis->unwatch();
        }catch(Exception $e){

        }

        return false;
    }

这样我们就很轻松的得到了借助于redis实现的分布式锁。但是这样的实现方式依然是有问题的。 问题1：如果在某个客户端获得锁后，redis主服务器宕机了，那么即使我们使用了主从备份，从属服务器被提升为主服务器，因为redis备份是异步的原因，这里的锁是没法及时同步到从属服务器的。 问题2：如果一个客户端在获得锁后，执行的操作超过了锁的有效期，锁被自动释放了。那么后续的操作是没法受到锁的保护的。 问题2的解决方案可以是watch，在获取锁后，可以立刻watch资源，然后再执行余下操作。 问题1的解决方案则是接下来要介绍的redlock算法

3.redlock

redlock算法是Redis的作者antirez提出来的。 可以被概述为以下几个步骤：

• 1.获取当前时间（毫秒数）:start_time。

• 2.按顺序获得N个Redis节点的锁（使用相同的key和identifier，并设置初始有效时间:init_validity_time）。在获得每个redis结点的锁的时候，都要设置一个timeout参数，这个timeout要远小于锁的自动释放时间。例如：如果锁的自动释放时间是10s，timeout应该为~5-55ms（还得视网络情况决定）。这样可以防止在获取锁时，节点宕机，导致耗时过长锁被释放了。如果获取锁失败则立刻获取下一个redis节点的锁

• 3.client计算为了获取锁花了多长时间：used_time = current_time - start_time。当且仅当client可以获取大多数实例的时候（至少N / 2 + 1个)，所花费的时间小于锁的有效时间，才认为获得了锁。

• 4.如果获得了锁，重新计算锁的有效时间:validity_time = init_validity_time - used_time

• 5.如果锁获取失败(无法获取N/2 + 1个节点的锁，或者有效时间validity_time是负数），则释放所有实例的锁（即使获得锁的时候失败了，这主要是考虑到有的时候锁获得成功了，但是告知客户端时网络异常）。

这很好的解决了上述的问题1，通过多个redis节点了来保证分布式锁服务的可靠性。

参考文章

Distributed locks with Redis 基于Redis的分布式锁到底安全吗（上）？ 基于Redis的分布式锁到底安全吗（下）？ redis事务 6.2.3 Building a lock in Redis

这里会放一些我觉得很好的博客、文章、资源等等。 The Knuth-Morris-Pratt Algorithm in my own words：这是一篇讲KMP的文章，非常详细易懂。KMP算法的next数组怎么求:https://blog.csdn.net/qq\_30974369/article/details/74276186 Go语言圣经（中文版）: go语言的教程，内容很详细，比较有深度。 Http|MDN: MDN一篇讲Http协议的文章。从基本概念，到缓存、Cookie、访问控制等方面进行详细的阐述。非常值得一看。 树形结构的数据库表Schema设计：一篇讲了在关系数据库中如何存储树形结构的博文。基于左右值的存储方式有一种b树的感觉。但是使用场景应该是较小的树形结构，不然在修改树的结构时效率很差。 Raft一致性算法论文译文，raft的视频，知乎上的一篇讲述,raft官网。图解raft 为什么能有上百万个Goroutines，却只能有上千个Java线程？：通过对比来了解go的协程。 Google I/O 2012 - Go Concurrency Patterns：如何在go中更好的使用它的并发模型。可以结合这篇PPT：https://talks.golang.org/2012/concurrency.slide#1 什么是异步io: 非常详细的讲解了linux中的异步IO的概念，使用 从Pod,Service,Ingress三个层面讲解k8s的网络 iptables iptables系列，非常详细易懂的讲解 Let’s Build A Simple Interpreter. 从 0 构建一个解释性语言。

什么是RBAC

RBAC，全称是Role-Based-Access-Control，可以译为基于角色的权限控制，是一种应用非常广泛的权限控制模型。

什么是角色(Role)

角色不是一个用户实体，而是代表了一组行为能力或责任的命名实体，以我们常用的QQ群为例，有以下角色：超级管理员、群主、管理员、普通成员、非群成员。 每个角色都有不同的权限:

• 超级管理员可以管理任何的QQ群，但是一般只能禁言、删除群，不能管理具体的某个群成员，也不能在群里聊天；
• 群主可以管理自己的QQ群，可以在群里聊天；
• 管理员可以管理自己的QQ群，可以聊天，但是不能解散群，也不能任命或撤销其他管理员；
• 普通成员则没有管理权限，只有在群里聊天的权限
• 非群成员无管理权限，也无法在群里聊天。

所以可以知道，每个角色都对应着一组行为能力或责任。

隐式的基于角色的权限控制

对于QQ群的例子来说。如果我们要做一个删除某个群成员的动作，伪代码可能如下:

if( user.hasRole('Group Owner') || user.hasRole('Group Manager') ){
    // delete the Group Member
} else {
    // Permission Denied
}

那么现在，如果腾讯的权限策略发生了改变，超级管理员也可以删除某个群的群成员来防止某些不当言论的传播，那么代码就要改为

if( user.hasRole('Group Owner') || user.hasRole('Group Manager') || user.hasRole('Super Manager') ){
    // delete the Group Member
} else {
    // Permission Denied
}

上面这种权限的管理方式，就可以称为隐式的基于角色的权限控制。因为Group Owner、Group Manager、Super Manager并不能显式的表达出：它们的角色具有删除群成员的权限。没有任何的代码显式的定义了这些角色的权限。我们只能从代码中隐式的推测出：这三个角色拥有删除群成员的权限。所以程序员们使用if/else语句来反映这些假设。

显式的基于角色的权限控制

了解了隐式的基于角色的权限控制，那么我们就可以知道，显式的基于角色的权限控制要有能力直接表达出：当前用户有权限去删除群成员。这样我们的代码可以调整如下：

if( user.isPermitted('GroupMember:delete:478') ){
    // delete the Group Member
} else {
    // Permission Denied
}

这样从代码中可以看到，如果当前用户被允许删除ID为478的群成员，那么就去删除，否则报权限不足的错误。至于isPermitted()中如何去判断权限的，可能依然是回到了哪些角色有哪些权限的问题。但是不同之处在于，应对上面的需求变更问题时，我们只需要更改user的isPermitted的判断规则，而不用去更改散布在代码中各个地方的if语句。可以做到以最小的变更来应对复杂的需求变化。

隐式 vs 显式

隐式和显式在我看来，其内在的权限控制仍然是一样的，都是基于角色在做权限判断。但对外的抽象则是截然不同的：隐式侧重于某个用户是否有某些角色，显式则直接将问题聚焦于某个用户是否有对某个资源的某个操作的权限。这在写代码中给程序员带来的影响是不一样的。截取一段项目中的代码来佐证：

//检查操作的权限
if(
    !$familyDB->isUserForFamily($familyId,$userId)&&
    !$familyDB->isAdminForFamily($familyId,$userId)&&
    !$familyDB->isOriginatorForFamily($familyId,$userId)
){
    Util::printResult( $GLOBALS['ERROR_PERMISSION'], "操作权限错误");
    exit;
}

这段代码判断了用户是否对家族有读取权限。因为我们是隐式的基于角色的权限控制，很直观的想法就是：家族成员、家族管理员、家族创始人这三个角色都有对家族的读取权限。所以这里判断了三个权限。事实上，家族创始人的判断是多余的，因为家族创始人肯定属于家族成员。但是真正在写代码的时候，很有可能考虑不到这个问题。 但如果是显式的基于角色的权限控制，这个if语句就是：

//检查操作的权限
if(
    !$familyDB->isUserHasReadPermission($familyId,$userId))
){
    Util::printResult( $GLOBALS['ERROR_PERMISSION'], "操作权限错误");
    exit;
}

程序员写代码时就不会做出多余的判断。可以得出，显式的抽象表达能力是明显更强的。

新的RBAC：Resource-Based-Access-Control

通过对比隐式和显式的区别，我们知道显式是直接检查某个用户对某个资源（Resource）是否有某个权限。所以不如直接抛弃角色（Role）的概念，将资源这个概念引入。这样就有了基于资源的权限控制（Resource-Based-Access-Control）。

1.ubuntu下的安装

通过 pecl 安装

pecl install xdebug

然后将xdebug.so加入php.ini中，注意如果使用的是fpm，则需要加入到fpm下的php.ini,同理cli环境下则需要向cli下的php.ini添加

zend_extension=“/usr/local/php/modules/xdebug.so”

注意:xdebug是zend的拓展，不需要添加extension=xdebug.so

通过编译安装

git clone git://github.com/xdebug/xdebug.git cd xdebug phpize ./configure –enable-xdebug make make install

2.配置php使用xdebug

xdebug有许多特性。

2.1 通过设置来影响var_dump()

影响var_dump()的属性有：

• xdebug.var_display_max_children,
• xdebug.var_display_max_data
• xdebug.var_display_max_depth

这三个属性的值都是数字类型的。会影响var_dump()函数显示的变量的内容长度和深度。 可以在php.ini做以下设置：

xdebug.var_display_max_depth = 2 xdebug.var_display_max_data = 8 xdebug.var_display_max_children = 3

具体的值可以自己手动调整 另外还有xdebug.cli_color和xdebug.overload_var_dump会影响到显示的效果

2.2 堆栈跟踪

演示脚本如下:

<?php
//这个脚本会超时
function foo( $a ) {
    for ($i = 1; $i < $a['foo']; $i++) {
        if ($i == 500000) xdebug_break();
    }
}

set_time_limit(1);
$c = new stdClass;
$c->bar = 100;
$a = array(
    42 => false, 'foo' => 9121240000000000,
    $c, new stdClass, fopen( '/etc/passwd', 'r' )
);
foo( $a );
?>

我们使用设置

xdebug.collect_params = 1

结果如下: 修改一下设置：

xdebug.collect_params = 3

可以看到浏览器中的报错信息更多了，体现在foo()函数中的参数数量 同样的，我们还可以设置

xdebug.dump_globals = On xdebug.dump.SERVER = ‘REQUEST_URI’

这样则可以展示一些超全局变量。这里指定了请求的URI 还可以设置

xdebug.show_local_vars = On

来展示程序运行期间的本地变量

2.3 函数跟踪

使用xdebug可以记录所有的函数调用。 测试脚本如下：

<?php

ini_set('xdebug.trace_format','0');

xdebug_start_trace();
$str = "Xdebug";
function ret_ord( $c )
{
    return ord( $c );
}

foreach ( str_split( $str ) as $char )
{
    echo $char, ": ", ret_ord( $char ), "\n";
}
xdebug_stop_trace();
?>

使用的设置如下:

;代码跟踪日志文件位置,注意要先新建这个/tmp/php_traces/fpm目录，并设置777
xdebug.auto_trace = Off
xdebug.trace_output_dir = /tmp/php_traces/fpm
;代码跟踪日志文件格式 
xdebug.trace_output_name = trace.%c.%p
;trace中显示函数的参数值，这个很有用，待会细说
xdebug.collect_params = 3
xdebug.collect_includes = On
xdebug.collect_return = On
xdebug.show_mem_delta = On
xdebug.var_display_max_depth = 2

结果如下: 通过调整xdebug.trace_format的值可以更改记录的格式。0是人类可读，1是机器可读，2是html

2.4远程调试

这里xdebug中非常好用的一个功能。通过设置，我们可以在IDE中单步调试。下面我会使用vscode来演示一遍。

2.4.1 环境准备

1.首先我们需要为vscode安装xdebug的插件。 2.配置好调试环境 这一步是在vscode左侧调试栏新增配置，然后选择php即可。 3.打上断点，启动调试 4.在浏览器中访问这个页面即可

参考链接

https://xdebug.org/docs/all#default

整个部署过程分为： 1.启用服务器的ipv6支持 2.申请ipv6通道 3.开启nginx的ipv6地址监听

1.ubuntu上开启ipv6支持，需要修改几个地方

1.开启ipv6支持，/etc/sysctl.conf 确保有以下设置：

net.ipv6.conf.all.disable_ipv6 = 0
net.ipv6.conf.default.disable_ipv6 = 0
net.ipv6.conf.lo.disable_ipv6 = 0

设置完毕后使用sysctl -p使设置生效 2.设置服务器的ipv6 dns服务器,/etc/network/interfaces 添加以下设置：

dns-nameserver 2001:4860:4860::8888
dns-nameserver 2001:4860:4860::8844

设置完毕后使用sudo resolvconf -u使设置生效 这样能够保证服务器在连接ipv6地址时有合适的dns服务器 测试:ping6 ipv6.google.com 如果能够ping通则表示已经设置成功

2.申请ipv6通道

因为我的服务器是没有分配ipv6地址的，所以需要去http://tunnelbroker.net申请ipv6的通道。 1.注册账号 2.邮箱激活 3.登录 4.create regular tunnel 5.输入你的服务器的ipv4地址，创建通道 6.在example configurations处选择操作系统，获取配置 7.在 /etc/network/interfaces中拷贝6中的配置 8.sudo resolvconf -u使配置生效 9.通过ifconfig查看是否设置成功，如果出现了ipv6的地址则表示成功

3.开启nginx的ipv6地址监听

在所有的站点配置文件中加上:

listen [::]:80
listen [::]:443

分别监听80端口和443端口(如果有https) 重启nginx即可。 通过http://ipv6-test.com/validate.php测试域名能否在ipv6下访问成功。如果是阿里云，那么有可能在IPv6 DNS server这一项上失败。因为阿里云的DNS服务器没有IPv6 DNS server。这种情况下，如果用户只有ipv6的环境，则会因为无法访问DNS服务器而失败

注意：下面的使用仅在ubuntu实验过。 1.打开ubuntu的core dump，这样程序出错后会生成corefile以供我们分析

echo '/tmp/corefile/core.%e.%p.%t' | sudo tee /proc/sys/kernel/core_pattern
ulimit -c unlimited

然后创建/tmp/corefile文件夹

mkdir /tmp/corefile/

2.运行程序，如果出现段错误（核心已转储），则说明corefile已经生成了。检查/tmp/corefile下是否有新生成的错误文件。 如果没有，执行cat /proc/sys/kernel/core_pattern，检查/tmp/corefile/core.%e.%p.%t是否写入了 3.使用gdb调试错误

所用工具

• tcpdump:linux下分析网络的一个好用的终端工具
• psysh:php的一个终端执行工具，可以很方便的在终端执行php代码
• curl:php的curl库

tcpdump报文中Flags代表报文类型: S (SYN), F (FIN), P (PUSH), R (RST), U (URG), W (ECN CWR), E (ECN-Echo) or ‘.’ (ACK), or ‘none’ if no flags are set.

分析背景

最近在了解swoole，因为公司的技术栈是php，所以之前用的java那一套在普通的php开发上完全用不了。为了让php有更好的性能，更广泛的使用场景，找了找相关资料，了解到swoole这个库。决定使用之后，项目中有个地方需要使用到http连接池，所以需要使用curl，但是curl虽然强大，但是参数实在是太多了，里面的实现细节也只能查看c的源代码才知道。所以只能曲线救国，通过tcpdump了解curl在http请求上的工作机制 tcpdump的使用方法是:

案例分析

案例一

只执行一次exec，等待一段时间，强制关闭终端进程

<?php
$context = curl_init();
curl_setopt($context,CURLOPT_URL,"http://www.izuqun.com");
curl_exec($context);

整个过程的报文如下

    `192.168.1.107.44664 > 116.62.25.128.http`: Flags [S], cksum 0x4bdf (correct), seq 3687066847, win 29200, options [mss 1460,sackOK,TS val 5931640 ecr 0,nop,wscale 7], length 0
16:28:54.014280 IP (tos 0x20, ttl 52, id 0, offset 0, flags [DF], proto TCP (6), length 60)

    `116.62.25.128.http > 192.168.1.107.44664`: Flags [S.], cksum 0xbcb5 (correct), seq 4174849842, ack 3687066848, win 28960, options [mss 1460,sackOK,TS val 3844377305 ecr 5931640,nop,wscale 7], length 0
16:28:54.014304 IP (tos 0x0, ttl 64, id 44712, offset 0, flags [DF], proto TCP (6), length 52)

    `192.168.1.107.44664 > 116.62.25.128.http`: Flags [.], cksum 0x5bba (correct), ack 1, win 229, options [nop,nop,TS val 5931643 ecr 3844377305], length 0
16:28:54.014334 IP (tos 0x0, ttl 64, id 44713, offset 0, flags [DF], proto TCP (6), length 105)

    `192.168.1.107.44664 > 116.62.25.128.http`: Flags [P.], cksum 0xee60 (correct), seq 1:54, ack 1, win 229, options [nop,nop,TS val 5931643 ecr 3844377305], length 53: HTTP, length: 53
        GET / HTTP/1.1
        Host: www.izuqun.com
        Accept: *\* 
16:28:54.023036 IP (tos 0x20, ttl 52, id 44520, offset 0, flags [DF], proto TCP (6), length 52)

    `116.62.25.128.http > 192.168.1.107.44664`: Flags [.], cksum 0x5b85 (correct), ack 54, win 227, options [nop,nop,TS val 3844377307 ecr 5931643], length 0
16:28:54.023061 IP (tos 0x20, ttl 52, id 44521, offset 0, flags [DF], proto TCP (6), length 314)
    `116.62.25.128.http > 192.168.1.107.44664`: Flags [P.], cksum 0xba4d (correct), seq 1:263, ack 54, win 227, options [nop,nop,TS val 3844377307 ecr 5931643], length 262: HTTP, length: 262
        HTTP/1.1 200 OK
        Server: nginx/1.12.2
        Date: Mon, 11 Dec 2017 08:28:54 GMT
        Content-Type: text/html
        Content-Length: 1243
        Last-Modified: Mon, 11 Dec 2017 02:35:33 GMT
        Connection: keep-alive
        Vary: Accept-Encoding
        ETag: "5a2deef5-4db"
        Accept-Ranges: bytes
16:28:54.023076 IP (tos 0x0, ttl 64, id 44714, offset 0, flags [DF], proto TCP (6), length 52)

    `192.168.1.107.44664 > 116.62.25.128.http`: Flags [.], cksum 0x5a73 (correct), ack 263, win 237, options [nop,nop,TS val 5931645 ecr 3844377307], length 0
16:28:54.024214 IP (tos 0x20, ttl 52, id 44522, offset 0, flags [DF], proto TCP (6), length 1295)

    `116.62.25.128.http > 192.168.1.107.44664`: Flags [P.], cksum 0x870b (correct), seq 263:1506, ack 54, win 227, options [nop,nop,TS val 3844377307 ecr 5931643], length 1243: HTTP
16:28:54.024236 IP (tos 0x0, ttl 64, id 44715, offset 0, flags [DF], proto TCP (6), length 52)

    `192.168.1.107.44664 > 116.62.25.128.http`: Flags [.], cksum 0x5585 (correct), ack 1506, win 256, options [nop,nop,TS val 5931645 ecr 3844377307], length 0

13报文：tcp的三次握手， 45报文：curl发起的get请求、服务器的ack回应 6~9报文：服务器对get请求的返回、我的机器的内核的ack，因为报文长度是超出了最大的限制，所以分成两次发送 稍等一会儿，又有新的报文

    `116.62.25.128.http > 192.168.1.107.44664`: Flags [F.], cksum 0x161d (correct), seq 1506, ack 54, win 227, options [nop,nop,TS val 3844393567 ecr 5931645], length 0
16:29:59.097967 IP (tos 0x0, ttl 64, id 44716, offset 0, flags [DF], proto TCP (6), length 52)
    `192.168.1.107.44664 > 116.62.25.128.http`: Flags [.], cksum 0xd672 (correct), ack 1507, win 256, options [nop,nop,TS val 5947914 ecr 3844393567], length 0

这是服务器发起的tcp连接关闭的报文，我的机器响应了，但是没有主动再次发送Fin 主动关闭psysh进程，出现大量报文

    192.168.1.107.44664 > 116.62.25.128.http: Flags [F.], cksum 0x8765 (correct), seq 54, ack 1507, win 256, options [nop,nop,TS val 5968150 ecr 3844393567], length 0
16:31:20.253999 IP (tos 0x0, ttl 64, id 44718, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44664 > 116.62.25.128.http: Flags [F.], cksum 0x8730 (correct), seq 54, ack 1507, win 256, options [nop,nop,TS val 5968203 ecr 3844393567], length 0
16:31:20.465940 IP (tos 0x0, ttl 64, id 44719, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44664 > 116.62.25.128.http: Flags [F.], cksum 0x86fb (correct), seq 54, ack 1507, win 256, options [nop,nop,TS val 5968256 ecr 3844393567], length 0
16:31:20.890008 IP (tos 0x0, ttl 64, id 44720, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44664 > 116.62.25.128.http: Flags [F.], cksum 0x8691 (correct), seq 54, ack 1507, win 256, options [nop,nop,TS val 5968362 ecr 3844393567], length 0
16:31:21.737935 IP (tos 0x0, ttl 64, id 44721, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44664 > 116.62.25.128.http: Flags [F.], cksum 0x85bd (correct), seq 54, ack 1507, win 256, options [nop,nop,TS val 5968574 ecr 3844393567], length 0
16:31:23.437992 IP (tos 0x0, ttl 64, id 44722, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44664 > 116.62.25.128.http: Flags [F.], cksum 0x8414 (correct), seq 54, ack 1507, win 256, options [nop,nop,TS val 5968999 ecr 3844393567], length 0
16:31:26.833967 IP (tos 0x0, ttl 64, id 44723, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44664 > 116.62.25.128.http: Flags [F.], cksum 0x80c3 (correct), seq 54, ack 1507, win 256, options [nop,nop,TS val 5969848 ecr 3844393567], length 0
16:31:33.633977 IP (tos 0x0, ttl 64, id 44724, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44664 > 116.62.25.128.http: Flags [F.], cksum 0x7a1f (correct), seq 54, ack 1507, win 256, options [nop,nop,TS val 5971548 ecr 3844393567], length 0
16:31:47.218007 IP (tos 0x0, ttl 64, id 44725, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44664 > 116.62.25.128.http: Flags [F.], cksum 0x6cdb (correct), seq 54, ack 1507, win 256, options [nop,nop,TS val 5974944 ecr 3844393567], length 0
16:32:14.417998 IP (tos 0x0, ttl 64, id 44726, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44664 > 116.62.25.128.http: Flags [F.], cksum 0x524b (correct), seq 54, ack 1507, win 256, options [nop,nop,TS val 5981744 ecr 3844393567], length 0

这些报文都是我的机器主动发送的关闭报文，但是服务器也不再响应

案例二

完整的使用curl_init和curl_close，显式关闭连接

<?php
$context = curl_init();
curl_setopt($context,CURLOPT_URL,"http://www.izuqun.com");
curl_exec($context);
curl_close($context);

报文如下

    192.168.1.107.44684 > 116.62.25.128.http: Flags [S], cksum 0x469f (correct), seq 2378041097, win 29200, options [mss 1460,sackOK,TS val 6028159 ecr 0,nop,wscale 7], length 0
16:35:20.090006 IP (tos 0x20, ttl 52, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    116.62.25.128.http > 192.168.1.107.44684: Flags [S.], cksum 0xd6a7 (correct), seq 3548165201, ack 2378041098, win 28960, options [mss 1460,sackOK,TS val 3844473825 ecr 6028159,nop,wscale 7], length 0
16:35:20.090050 IP (tos 0x0, ttl 64, id 64631, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44684 > 116.62.25.128.http: Flags [.], cksum 0x75ac (correct), ack 1, win 229, options [nop,nop,TS val 6028162 ecr 3844473825], length 0
16:35:20.090105 IP (tos 0x0, ttl 64, id 64632, offset 0, flags [DF], proto TCP (6), length 105)
    192.168.1.107.44684 > 116.62.25.128.http: Flags [P.], cksum 0x0853 (correct), seq 1:54, ack 1, win 229, options [nop,nop,TS val 6028162 ecr 3844473825], length 53: HTTP, length: 53
        GET / HTTP/1.1
        Host: www.izuqun.com
        Accept: */*

16:35:20.099626 IP (tos 0x20, ttl 52, id 47030, offset 0, flags [DF], proto TCP (6), length 52)
    116.62.25.128.http > 192.168.1.107.44684: Flags [.], cksum 0x7576 (correct), ack 54, win 227, options [nop,nop,TS val 3844473828 ecr 6028162], length 0
16:35:20.099655 IP (tos 0x20, ttl 52, id 47031, offset 0, flags [DF], proto TCP (6), length 314)
    116.62.25.128.http > 192.168.1.107.44684: Flags [P.], cksum 0xda41 (correct), seq 1:263, ack 54, win 227, options [nop,nop,TS val 3844473828 ecr 6028162], length 262: HTTP, length: 262
        HTTP/1.1 200 OK
        Server: nginx/1.12.2
        Date: Mon, 11 Dec 2017 08:35:20 GMT
        Content-Type: text/html
        Content-Length: 1243
        Last-Modified: Mon, 11 Dec 2017 02:35:33 GMT
        Connection: keep-alive
        Vary: Accept-Encoding
        ETag: "5a2deef5-4db"
        Accept-Ranges: bytes

16:35:20.099670 IP (tos 0x0, ttl 64, id 64633, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44684 > 116.62.25.128.http: Flags [.], cksum 0x7464 (correct), ack 263, win 237, options [nop,nop,TS val 6028164 ecr 3844473828], length 0
16:35:20.099680 IP (tos 0x20, ttl 52, id 47032, offset 0, flags [DF], proto TCP (6), length 1295)
    116.62.25.128.http > 192.168.1.107.44684: Flags [P.], cksum 0xa0fc (correct), seq 263:1506, ack 54, win 227, options [nop,nop,TS val 3844473828 ecr 6028162], length 1243: HTTP
16:35:20.099686 IP (tos 0x0, ttl 64, id 64634, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44684 > 116.62.25.128.http: Flags [.], cksum 0x6f76 (correct), ack 1506, win 256, options [nop,nop,TS val 6028164 ecr 3844473828], length 0

这边的报文一开始和案例一完全一致，但是在我使用curl_close()显式关闭curl后，并没有发送任何关闭tcp连接的报文。查了一下资料，在php7.0中，如果$context任何有全局引用，即使使用curl_close()显式关闭，也不会关闭连接。

案例3

完整的使用curl_init和curl_close，显式关闭连接，并且多次执行exec

16:38:26.590098 IP (tos 0x0, ttl 64, id 18826, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.107.44714 > 116.62.25.128.http: Flags [S], cksum 0x520f (correct), seq 3672832041, win 29200, options [mss 1460,sackOK,TS val 6074787 ecr 0,nop,wscale 7], length 0
16:38:26.604823 IP (tos 0x20, ttl 52, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    116.62.25.128.http > 192.168.1.107.44714: Flags [S.], cksum 0xf795 (correct), seq 3884635295, ack 3672832042, win 28960, options [mss 1460,sackOK,TS val 3844520454 ecr 6074787,nop,wscale 7], length 0
16:38:26.604870 IP (tos 0x0, ttl 64, id 18827, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44714 > 116.62.25.128.http: Flags [.], cksum 0x969a (correct), ack 1, win 229, options [nop,nop,TS val 6074790 ecr 3844520454], length 0
16:38:26.604904 IP (tos 0x0, ttl 64, id 18828, offset 0, flags [DF], proto TCP (6), length 105)
    192.168.1.107.44714 > 116.62.25.128.http: Flags [P.], cksum 0x2941 (correct), seq 1:54, ack 1, win 229, options [nop,nop,TS val 6074790 ecr 3844520454], length 53: HTTP, length: 53
        GET / HTTP/1.1
        Host: www.izuqun.com
        Accept: */*

16:38:26.616651 IP (tos 0x20, ttl 52, id 28329, offset 0, flags [DF], proto TCP (6), length 52)
    116.62.25.128.http > 192.168.1.107.44714: Flags [.], cksum 0x9664 (correct), ack 54, win 227, options [nop,nop,TS val 3844520457 ecr 6074790], length 0
16:38:26.616674 IP (tos 0x20, ttl 52, id 28330, offset 0, flags [DF], proto TCP (6), length 314)
    116.62.25.128.http > 192.168.1.107.44714: Flags [P.], cksum 0xf829 (correct), seq 1:263, ack 54, win 227, options [nop,nop,TS val 3844520457 ecr 6074790], length 262: HTTP, length: 262
        HTTP/1.1 200 OK
        Server: nginx/1.12.2
        Date: Mon, 11 Dec 2017 08:38:26 GMT
        Content-Type: text/html
        Content-Length: 1243
        Last-Modified: Mon, 11 Dec 2017 02:35:33 GMT
        Connection: keep-alive
        Vary: Accept-Encoding
        ETag: "5a2deef5-4db"
        Accept-Ranges: bytes

16:38:26.616687 IP (tos 0x0, ttl 64, id 18829, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44714 > 116.62.25.128.http: Flags [.], cksum 0x9551 (correct), ack 263, win 237, options [nop,nop,TS val 6074793 ecr 3844520457], length 0
16:38:26.616701 IP (tos 0x20, ttl 52, id 28331, offset 0, flags [DF], proto TCP (6), length 1295)
    116.62.25.128.http > 192.168.1.107.44714: Flags [P.], cksum 0xc1ea (correct), seq 263:1506, ack 54, win 227, options [nop,nop,TS val 3844520457 ecr 6074790], length 1243: HTTP
16:38:26.616708 IP (tos 0x0, ttl 64, id 18830, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44714 > 116.62.25.128.http: Flags [.], cksum 0x9063 (correct), ack 1506, win 256, options [nop,nop,TS val 6074793 ecr 3844520457], length 0
16:38:28.241841 IP (tos 0x0, ttl 64, id 18831, offset 0, flags [DF], proto TCP (6), length 105)
    192.168.1.107.44714 > 116.62.25.128.http: Flags [P.], cksum 0x2174 (correct), seq 54:107, ack 1506, win 256, options [nop,nop,TS val 6075199 ecr 3844520457], length 53: HTTP, length: 53
        GET / HTTP/1.1
        Host: www.izuqun.com
        Accept: */*

16:38:28.253636 IP (tos 0x20, ttl 52, id 28332, offset 0, flags [DF], proto TCP (6), length 314)
    116.62.25.128.http > 192.168.1.107.44714: Flags [P.], cksum 0xeede (correct), seq 1506:1768, ack 107, win 227, options [nop,nop,TS val 3844520867 ecr 6075199], length 262: HTTP, length: 262
        HTTP/1.1 200 OK
        Server: nginx/1.12.2
        Date: Mon, 11 Dec 2017 08:38:28 GMT
        Content-Type: text/html
        Content-Length: 1243
        Last-Modified: Mon, 11 Dec 2017 02:35:33 GMT
        Connection: keep-alive
        Vary: Accept-Encoding
        ETag: "5a2deef5-4db"
        Accept-Ranges: bytes

16:38:28.253689 IP (tos 0x0, ttl 64, id 18832, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44714 > 116.62.25.128.http: Flags [.], cksum 0x8be1 (correct), ack 1768, win 276, options [nop,nop,TS val 6075202 ecr 3844520867], length 0
16:38:28.253704 IP (tos 0x20, ttl 52, id 28333, offset 0, flags [DF], proto TCP (6), length 1295)
    116.62.25.128.http > 192.168.1.107.44714: Flags [P.], cksum 0xb8a1 (correct), seq 1768:3011, ack 107, win 227, options [nop,nop,TS val 3844520867 ecr 6075199], length 1243: HTTP
16:38:28.253713 IP (tos 0x0, ttl 64, id 18833, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.107.44714 > 116.62.25.128.http: Flags [.], cksum 0x86f3 (correct), ack 3011, win 295, options [nop,nop,TS val 6075202 ecr 3844520867], length 0

多次curl_exec()会复用之前的连接，但是curl_close()依然是不能关闭连接的。但当我使用unset($context)时，观察到了以下报文：

    192.168.1.107.49938 > 116.62.25.128.http: Flags [F.], cksum 0x8407 (correct), seq 54, ack 1506, win 256, options [nop,nop,TS val 274723 ecr 3860448314], length 0                                                                                                      
10:20:58.408173 IP (tos 0x20, ttl 52, id 25537, offset 0, flags [DF], proto TCP (6), length 52)                                      
    116.62.25.128.http > 192.168.1.107.49938: Flags [F.], cksum 0x5ca5 (correct), seq 1506, ack 55, win 227, options [nop,nop,TS val 3860458424 ecr 274723], length 0                                                                                                      
10:20:58.408218 IP (tos 0x0, ttl 64, id 34603, offset 0, flags [DF], proto TCP (6), length 52)                                       
    192.168.1.107.49938 > 116.62.25.128.http: Flags [.], cksum 0x5c85 (correct), ack 1507, win 256, options [nop,nop,TS val 274726 ecr 3860458424], length 0 

我的机器主动关闭连接发出Fin，服务器ack并发送Fin,我的机器也ack。两边顺利的完成了连接的关闭。 所以当前可以得出以下几点: 1.$context = curl_init(), $context是可以复用的，复用$context后，多次执行curl_exec()可以避免tcp的3次握手和4次断开的过程。 2.curl_close()在上面的试验中，并不能正常的关闭连接，这是因为在psysh的执行环境中，$context一直是在当前的作用域，会一直保持着变量的引用。而php7.0中，$context如果保持引用，curl_close则不会关闭连接，而unset($context)则会关闭。 3.服务器主动关闭连接后发出Fin，我的机器虽然响应了ack，但是没有主动发送Fin，这会不会导致服务器大量的fin_wait2？ 第三点是很重要的，如果不解决会大量占用服务器资源。 所以再做一个实验，实验过程如下：

• 我的机器初始化大量的curl_init()，然后不释放，等待服务器关闭。使用netstat查看服务器是否会出现大量的fin_wait2。

使用netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c可以快速查看各种tcp连接状态的统计。 初始情况为：

20 CLOSE_WAIT
63 ESTABLISHED                                                                              
10 LISTEN

psysh中执行以下脚本

$contextArr = array();
for($i = 0; $i < 1000; $i++){
    $contextArr[$i] = curl_init();
    curl_setopt($contextArr[$i],CURLOPT_URL,"http://www.izuqun.com");
    curl_exec($contextArr[$i]);
}

脚本执行完后，服务器状态变化如下：

20 CLOSE_WAIT
1058 ESTABLISHED
5 FIN_WAIT2
10 LISTEN
2 TIME_WAIT

20 CLOSE_WAIT
58 ESTABLISHED
1001 FIN_WAIT2
10 LISTEN

20 CLOSE_WAIT
63 ESTABLISHED
10 LISTEN

可以看到，中间有1000个FIN_WAIT2状态，说明我们的猜想是正确的。

一.简介

首页这里引用一下swoole的官方介绍:

swoole:面向生产环境的 PHP 异步网络通信引擎 使 PHP 开发人员可以编写高性能的异步并发 TCP、UDP、Unix Socket、HTTP，WebSocket 服务。Swoole 可以广泛应用于互联网、移动通信、企业软件、云计算、网络游戏、物联网（IOT）、车联网、智能家居等领域。 使用 PHP + Swoole 作为网络通信框架，可以使企业 IT 研发团队的效率大大提升，更加专注于开发创新产品。

通过上述的介绍,我们是可以得出几点信息的

• 1.swoole可以投入生产环境
• 2.使用php编写
• 3.异步网络通信引擎,支持大量的网络协议,并且具有很高的网络性能

swoole server与传统的php运行模式是完全不同的,它是常驻内存的,省去了大量的php脚本的初始化。

二.swoole server的是怎么运行的

这是一张官方的swoole运行时进程/线程模型。

1.Master进程

Master进程是一个多线程模型,其中包括Master线程,Reactor线程组,心跳检测线程,UDP收包线程。 以http server为例,Master线程负责监听(listen)端口,然后接受(accept)新的连接,然后将这个连接分配给一个Reactor线程,由这个Reactor线程监听此连接,一旦此连接可读时,读取数据,解析协议,然后将请求投递到worker进程中去执行。 Master进程是使用select/poll进行IO事件循环的,这是因为Master进程中的文件描述符只有几个(listenfd等),Reactor线程使用的是epoll,因为Reactor线程中会监听大量连接的可读事件,使用epoll可以支持大量的文件描述符。

2.Manager进程

Manager进程是专门用来管理Worker进程组和Task进程组的。它会Fork出指定数量的Worker进程和Task进程，并且有以下职能:

• 子进程结束运行时，manager进程负责回收此子进程，避免成为僵尸进程。并创建新的子进程
• 服务器关闭时，manager进程将发送信号给所有子进程，通知子进程关闭服务
• 服务器reload时，manager进程会逐个关闭/重启子进程

3.Worker进程和Task进程

Worker进程接收Reactor线程投递过来的数据，执行php代码，然后生成数据交给Reactor线程，由Reactor线程通过tcp将数据返回给客户端。（如果是UDP，Worker进程直接将数据发送给客户端）。 Worker进程中执行的php代码和我们平时写php是一样的，它等同于php-fpm。但是众所周知，php-fpm下，php在处理异步操作时是很无力的，swoole提供的Task进程可以很好的解决这个问题。Worker进程可以将一些异步任务投递给Task进程，然后直接返回，处理其他的由Reactor线程投递过来的事件。 Task进程以完全同步阻塞的方式运行，一个Task进程在执行任务期间，是不接受从Worker进程投递的任务的，当Task进程执行完任务后，会异步地通知worker进程告诉它此任务已经完成。 所以介绍完上述的一些概念后，再引用一张官方的swoole执行流程图。 这里需要注意，在文档上说的是：Workder进程组和Task进程组是由Manager进程Fork出来的，但是流程图上画的是在启动服务器时Fork出主进程和Worker进程组以及Tasker进程组。

三、使用swoole和传统php开发的优缺点

在说这个话题之前，需要先了解一下CGI,FASTCGI。 1.CGI CGI的全称是Common Gateway Interface,通用网关接口，它使得任何一个拥有标准输入输出的程序拥有提供web server的能力。假设我们写了一个Hello World的c++程序,这个程序接受输入{text},输出{text},Hello World。 以nginx作为接受http请求为例，nginx接受一个http请求，Fork出一个进程，将http请求带来的text参数作为输入，执行完hello world程序，将输出{text},Hello World作为输出，销毁这个Fork出来的进程，由nginx返回给客户端。 这种方式虽然简单，但是要不断的Fork进程，销毁进程。 2.FASTCGI FASTCGI，顾名思义，它是CGI的改进版，是一个常驻型的CGI服务。我们常用的php-fpm就是这种模式运行的，php-fpm负责Forl多个进程，每个进程中都运行了php的解释器。可以在终端下看一下php-fpm的进程： 一个php-fpm主进程,pid是1263,Fork出了3个子进程。在nginx+php-fpm的组合中，nginx负责接受http请求，将请求封装好交给php-fpm，php-fpm将请求按照一定的规则交给一个子进程去执行，这个子进程中的php解释器加载php代码运行。也是因为这个原因，传统的php只能作为web server。 然后我们发现，nginx+php-fpm的组合和我们Reactor+Worker子进程的运行方式非常相似。 3.swoole的运行方式 这里以swoole作为http server为例（传统php几乎都是作为web服务）。 首先swoole是实现了http server的，也就是说不需要nginx作为http服务器了，当然swoole并不是为了取代nginx，实际上swoole当前实现的http server功能有限，比如说只支持Get和Post，所有往往swoole前面还要运行一个nginx来作为前端代理服务器。 其次，swoole是内存常驻的。和php-fpm的常驻服务不同，php-fpm中常驻的是php的解释器，这个解释器会重复加载php代码，初始化环境，而swoole只在启动的时候加载，这样一来，性能就自然而然的提高了。这一点可以在开发中很明显的体现出来，php-fpm下，修改的php代码会即时生效，而使用swoole则需要重启swoole的server才能使代码生效。 通过上面的一些说明，就可以很明显的得出swoole和传统php开发的优缺点了。 swoole server优点： - swoole性能更高 - 可以做为tcp,udp服务器 - 在高io高并发的服务器要求下，swoole的运行模式是完全可以胜任的 swoole server缺点： - 更难上手。这要求开发人员对于多进程的运行模式有更清晰的认识 - 更容易内存泄露。在处理全局变量，静态变量的时候一定要小心，这种不会被GC清理的变量会存在整个生命周期中，如果没有正确的处理，很容易消耗完所有的内存。而以往的php-fpm下，php代码执行完内存就会被完全释放。 - 无法做密集计算。当然这一点是php甚至是所有动态语言都存在的问题。写在这里是因为防止误导读者以为使用swoole后，php可以用来做密集计算。

1.简介

　png图片格式采用了一种很灵活的编码设计，支持多种编码方式来展示一张图片：灰度图片、索引彩色图像、真彩色图像、带α通道数据的灰度图像、带α通道数据的真彩色图像。因为png的编码方式灵活，使得其压缩的发挥空间非常大。

2.几种编码方式的说明

注意：这里的一个通道并不等同于1个字节或2个字节，因为png IDAT块的编码单位是bit而不是byte，具体一个通道占用的位数是靠bit depth来决定的

a.灰度图片

灰度图片一般是用来生成我们常见的黑白照片，bit depth可选值为1、 2、 4、 8、16，其一个像素点用一个通道来表示（0255）或(065535)，因此这种图片的大小往往非常小

b.索引彩色图像

索引彩色图像很有意思，它可以和真彩色图像一样拥有表达彩色图片的能力，但是一张索引彩色图像上最多只有256种颜色，每种颜色用三个字节(RGB,0255)表示。它的bit depth可选值为1、 2、4、8，它有一个调色板区域，用来记录索引颜色的值，然后像素点数据区域用一个通道(0255)来表示调色板区域记录的颜色索引。所以对于色彩不多的图片来说，采用索引彩色来编码是很适合的。

c.真彩色图像

真彩色图像最好理解，它的bit depth为8或16，它的每个像素点都用3个字节(3个通道）来表示，分别为R(0255),G(0255),B(0255)，可以表达256_256_256=16777216种颜色，或者使用6个字节（3个通道）来表示，分别为R(065535),G(065535),B(065535)，可以表达65535_65535_65535种颜色。

d.带α通道数据的灰度图像

就是在灰度图片上增加了α通道，共2个通道,支持透明(0255)或者(065535)，但是它的bit depth为8或16，因此这种编码方式一个像素点是2个字节或4个字节

e.带α通道数据的真彩色图像

就是在真彩色图像上增加了α通道,同四个通道，支持透明(0255)或者(065535)，它的bit depth为8或16，因此这种编码方式一个像素点是4个字节或8个字节

3.png图片具体编码说明

png图片的编码一般如下:header,chunk,chunk,chunk….chunk。 header代表png图片的头，png文件头一般都是由固定的8个字节组成 89 50 4E 47 OD 0A 1A 0A 图片软件可以通过这8个字节来判断这个文件是不是png格式。 chunk代表png图片的数据块，数据块是有不同的类型的，记录了不同的信息。一张png图片可能包含多个数据块。 数据块的类型如下（关键部分高亮显示）: PNG文件格式中的数据块（表1.1）

数据块符号	数据块名称	多数据块	可选否	位置限制
IHDR	文件头数据块	否	否	第一块
cHRM	基色和白色点数据块	否	是	在PLTE和IDAT之前
gAMA	图像γ数据块	否	是	在PLTE和IDAT之前
sBIT	样本有效位数据块	否	是	在PLTE和IDAT之前
PLTE	调色板数据块	否	是	在IDAT之前
bKGD	背景颜色数据块	否	是	在PLTE之后IDAT之前
hIST	图像直方图数据块	否	是	在PLTE之后IDAT之前
tRNS	图像透明数据块	否	是	在PLTE之后IDAT之前
oFFs	(专用公共数据块)	否	是	在IDAT之前
pHYs	物理像素尺寸数据块	否	是	在IDAT之前
sCAL	(专用公共数据块)	否	是	在IDAT之前
IDAT	图像数据块	是	否	与其他IDAT连续
tIME	图像最后修改时间数据块	否	是	无限制
tEXt	文本信息数据块	是	是	无限制
zTXt	压缩文本数据块	是	是	无限制
fRAc	(专用公共数据块)	是	是	无限制
gIFg	(专用公共数据块)	是	是	无限制
gIFt	(专用公共数据块)	是	是	无限制
gIFx	(专用公共数据块)	是	是	无限制
IEND	图像结束数据	否	否	最后一个数据块

png 文件中，每个数据块由4个部分组成 length | type(name) | data | CRC, 说明如下 length: 4 bytes， data的长度，不包括type和CRC type: 4 bytes, ASCII码([A-Z,a-z]) CRC: 4bytes CRC(cyclic redundancy check)域中的值是对Chunk Type Code域和Chunk Data域中的数据进行计算得到的。CRC具体算法定义在ISO 3309和ITU-T V.42中，其值按下面的CRC码生成多项式进行计算： x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1 除了高亮的关键数据块，还有下面比较有意思的数据块 tRNS

tRNS contains transparency information. For indexed images, it stores alpha channel values for one or more palette entries. For truecolor and grayscale images, it stores a single pixel value that is to be regarded as fully transparent.

tRNS包含透明度信息， 1.在索引图片中，它可以保存一或多个调色板像素对的alpha通道值。用来指明哪些像素需要透明，透明度是多少。然后剩下的像素透明度都被默认成255，完全不透明。 2.在灰度图片中，包含单个灰度级别值，格式如下： Gray: 2 bytes, range 0 .. (2^bitdepth)-1 被指定的灰度值都会被当成是透明的，其他灰度值则完全不透明（如果bit depth小于16，则取最低有效位，其他位为0） 3.在真彩色图片中，包含单个RGB颜色值，格式如下： Red: 2 bytes, range 0 .. (2^bitdepth)-1 Green: 2 bytes, range 0 .. (2^bitdepth)-1 Blue: 2 bytes, range 0 .. (2^bitdepth)-1 被指定的颜色值都会被当成是透明的，其他颜色值则完全不透明（如果bit depth小于16，则取最低有效位，其他位为0） 在带alpha通道的图片中，tRNS是被禁止使用的。

a.IHDR数据块

IHDR数据块存储了png图像的基本信息，一个图像中只能有一个IHDR数据块，并且也是png图像的第一个数据块。共有13个字节。记录的信息如下： 表1.2

域的名称	字节数	说明
Width	4 bytes	图像宽度，以像素为单位
Height	4 bytes	图像高度，以像素为单位
Bit depth	1 byte	图像深度.索引彩色图像： 1，2，4或8 , 灰度图像： 1，2，4，8或16 真彩色图像： 8或16
ColorType	1 byte	颜色类型. [0]：灰度图像, 1，2，4，8或16 [2]：真彩色图像，8或16 [3]：索引彩色图像，1，2，4或8 [4]：带α通道数据的灰度图像，8或16 [6]：带α通道数据的真彩色图像，8或16
Compression method	1 byte	压缩方法(LZ77派生算法)
Filter method	1 byte	滤波器方法
Interlace method	1 byte	隔行扫描方法. 0：非隔行扫描 1： Adam7(由Adam M. Costello开发的7遍隔行扫描方法)

从这个表中可以得出，一张png图片最大的宽高（4294967300 × 4294967300） 这里的Bit depth一开始很难理解，引用维基百科两段话：

Pixels in PNG images are numbers that may be either indices of sample data in the palette or the sample data itself. The palette is a separate table contained in the PLTE chunk. Sample data for a single pixel consists of a tuple of between one and four numbers. Whether the pixel data represents palette indices or explicit sample values, the numbers are referred to as channels and every number in the image is encoded with an identical format. The permitted formats encode each number as an unsigned integral value using a fixed number of bits, referred to in the PNG specification as the bit depth. Notice that this is not the same as color depth, which is commonly used to refer to the total number of bits in each pixel, not each channel. The permitted bit depths are summarized in the table along with the total number of bits used for each pixel. The number of channels depends on whether the image is grayscale or color and whether it has an alpha channel. PNG allows the following combinations of channels, called the color type.

大意是：png图片的像素(Pixels)是调色板中样本数据的索引或者样本数据其本身，调色板是在PLTE数据块中的。单个像素的样本数据包含1~4个数字的元组。像素数据表示调色板索引或者明确的样本值，每个数字代表每个通道，每个数字都有唯一可识别的编码。 允许编码每个数字的格式是一个使用固定位数的unsigned整数值，在PNG中称为bit depth(位深)。位深和color depth(颜色深度)不同，颜色深度通常代表一个像素的总位数，不是每个通道的总位数。 通道数取决于这个图片是否是灰度图还是有alpha通道的色彩图 因此可以知道bit depth是一个通道的位数，bit depth在索引彩色图片和灰度图中使用，使得图片的一个像素点的大小可以小于一个字节

b.PLTE数据块（调色板数据块）

• a.PLTE数据块在索引彩色图像中必须存在，这里记录了整张图片所有的颜色，最多为256个。这个是bit depth规定的，由表1.2可知，索引彩色图像的bit depth为1,2,4,8，共为1、4、16、256种颜色。每种颜色是3个字节（RGB)，所以PLTE数据块的length肯定是3的倍数，否则就是非法的。

• b.PLTE数据块在真彩色图像或带α通道数据的真彩色图像中是可选的

• c.PLTE数据块在灰度图像或带α通道数据的灰度图像中是不能存在的

c.IDAT数据块

这部分的数据块存放的就是图像的一个个像素（使用压缩算法之后生成的像素），一张图像中可以存在多个IDAT数据块，这种编码方式虽然稍微增加了图像的大小，但是可以使得PNG图像以一种流的方式生成。例如在浏览器中打开一张非常大的PNG图像，如果网络很慢，我们可以看到图片是从上到下一点点打开的，这是因为即使整张图片没有加载完，仍然可以显示局部内容。 IDAT数据块是最重要的一部分，这里的数据会被隔行扫描方法(Interlace method)、滤波器（filtering）和压缩算法(compression)处理。这三个部分会在下面详细介绍。 并且要注意的是，IDAT数据块存储的数据并不是以字节为最小单位，在灰度图片和索引彩色图片中，一个字节可能会包含多个像素点，由bit depth指定。

d.IENT数据块

这段数据块标记PNG文件或者数据流已经结束，并且必须要放在文件的尾部。 正常情况下， png 文件的结尾为如下12个字符： 00 00 00 00 49 45 4E 44 AE 42 60 82 由于数据块结构的定义，IEND数据块的长度总是0（00 00 00 00，除非人为加入信息），数据标识总是IEND（49 45 4E 44），因此，CRC码也总是AE 42 60 82

4.隔行扫描方法

隔行扫描方法是为了图片被更先进的展示出来。在图片传输过程中，可以让图片的展示有淡入的效果。虽然平均下来稍微增加了存储的大小，但是给带来用户更快的显示效果。

• a.这个方法取值为0时，代表像素点是从左到右顺序存储，扫描线扫描时从上到下即可。

• b.这个方法取值为1时，被称为Adam7算法 Adam7分为7个扫描步骤，可见下图：

  5.过滤器

  过滤器中只有一种过滤方法，但是有多种过滤类型。过滤方法并不会影响数据的大小，也不会影响丢失任何信息，过滤的目的只有一个，为压缩方法提供更好压缩的数据，IDAT数据中的每一行第一个字节定义了过滤类型，过滤类型的介绍如下:

  a.过滤类型0：None

  也就是不做任何过滤

  b. 过滤类型1：Sub

  记录当前像素和左边像素的差值。左边起第一个像素是标准值，不做任何过滤

  c. 过滤类型2：Up

  记录X - B的值，即当前像素和上边像素点差值。如果当前行是第1行，则当前行数标准值，不做任何过滤。

  d.过滤类型3：Average

  记录当前像素与左边像素和上边像素的平均值的差值。

  • 如果当前行数第一行：做特殊的Sub过滤，左边起第一个像素是标准值，不做任何过滤。其他像素记录该像素与左边像素的二分之一的值的差值。

• 如果当前行数不是第一行：左边起第一个像素记录该像素与上边像素的二分之一的值的差值，其他像素做正常的Average过滤。

  e.过滤类型4：Paeth

  记录X - Pr的值，这种过滤方式比较复杂，Pr的计算方式（伪代码）如下：

p = a + b - c
pa = abs(p - a)
pb = abs(p - b)
pc = abs(p - c)
if pa <= pb and pa <= pc then Pr = a
else if pb <= pc then Pr = b
else Pr = c
return Pr

如果当前行数第一行：做Sub过滤。 如果当前行数不是第一行：左边起第一个像素记录该像素与上边像素的差值，其他像素做正常的Peath过滤。

6.压缩算法

压缩算法当前只定义了一种，值为0，是使用一个滑动窗口的deflate/inflate压缩，这个算法可以调用zlib库来实现

7.关于压缩

对于一张图片，我们可以使用以上知识来完成一次无损压缩,以及去除所有的辅助数据块。但是很多场景下，常规的无损压缩并不能带来很高的压缩比，这个时候可以考虑使用有损压缩，大概的思路就是将总体颜色数减少到256以下（使用相近的颜色来代替），然后使用索引色彩来编码整张图片，带来很高的压缩比

实际操作验证

一级压缩图片（958.8k）：/uploads/wp/2017/11/output_1.png 九级压缩图片（857.0k）：/uploads/wp/2017/11/output_9.png 有损压缩图片（273.0k）：/uploads/wp/2017/11/test_tiny.png 原图（1.5m）：/uploads/wp/2017/11/test.png) 使用vim打开原图: 8950 4e47 0d0a 1a0a是png固定的头, 0000 000d是iHDR数据块的长度，为13，4948 4452是数据块的type,为IHDR，之后紧跟着是data， 0000 02bc是图片的宽度,0000 03a5是高度，08是Bit depth，也就是一个通道是8位,06是color type,这里表示图片是真彩色，00是压缩方法，png中目前只有一种，也就是LZ77派生的算法，00是滤波器方法，表示不使用，00是隔行扫描方法，代表不扫描。8f 1434 a4是四个字节的CRC校验码。 00 0000 01是sRGB数据块的长度（???)，为1，73 5247 42是type,为sRGB，00是存储的一个字节数据，aece 1ce9是循环校验码 之后还有一个iDoT数据块，再紧接着才是IDAT数据块，下面就不分析了。 再打开9级压缩的图片 简单看一下，sRGB和iDOT数据块已经不存在了,IDAT数据块的长度发生了改变，其实就是被压缩了。这种压缩是无损的，9级压缩和1级压缩相差十几k的大小，但是压缩的越小，耗时也越长。 最后去看在tinypng上进行有损压缩的图片: 它多了一个PLTE字段，意味着这张图变成了索引彩色图片，索引彩色图片最关键的一点就是总颜色数不能超过256。如果这张图片的总颜色数没有256个，那么甚至可以说这次图片的压缩是无损的。但是一旦颜色数超过256，就需要将多个相近的颜色处理成一个颜色，也就是有损的压缩

参考

• [1] png文件结构分析:http://www.360doc.com/content/11/0428/12/1016783\_112894280.shtml
• [2] php imagecreatefrom* 系列函数之 png：http://drops.xmd5.com/static/drops/tips-16034.html
• [3] Portable Network Graphics: https://en.wikipedia.org/wiki/Portable\_Network\_Graphics
• [4] png的故事：获取图片信息和像素内容: https://www.qcloud.com/community/article/864088
• [5] https://www.w3.org/TR/2003/REC-PNG-20031110/#figure48

一、前言

缓存在整个计算机体系中，占据着举足轻重的地位，往往被用于提升软件的运行速度。在计算机系统中，最典型的当属CPU高速缓存了，CPU高速缓存是介于CPU寄存器和内存之间，CPU向内存中请求数据时，会先检查CPU高速缓存中是否存在数据，如果不存在，则会将内存中的数据放入高速缓存中，再将高速缓存中的数据读入CPU。这个过程中，缓存之所以能够大大的提升系统速度，是因为程序在运行的时候对内存的访问具有局部性的特点，这种局部性我理解为程序在运行时对某一块的内存请求会非常频繁，而这一块内存在第一次请求之后就会被缓存，所以会大大提升之后的数据读取速度。所以，缓存设计的是否合理有效，在于缓存的命中率高不高。 在leveldb中，为了提升对数据的检索速度，也设计了缓存，对应的代码在db/table_cache.h和db/table_cache.cc中，这个table cache的实现主要借助于Cache类，关于Cache类，是可以用户自定义实现的，但leveldb也有一个内置的Cache的实现，文件是util/cache.cc。主要是LRU（最近最少使用）算法，原理是“如果一个数据最近被使用，那么将来被使用的概率同样也很大”。同样也实现了一个HashTable，leveldb中提供的数据显示在g++ 4.4.3下比built-in的哈希表性能稍高，大概5%左右。

二、概览

2.1 hash table数据结构

哈希表是一个很常见的结构了，存储的是key-value结构，一个key-value对常被称作entry，它最大的特点是查找快。在网上找了一张hash table的图 首先它是一个长为len的数组，每个数组中的元素都是一个链表。如图所示，john Smith和Sandra Dee都被hash到152这个地方，所以在152这个地方使用链表来存储这两个entry.查找的时候Sandra Dee的时候，先找到152这个地方，在遍历链表，直到找到key是Sandra的entry。

2.2 LRU算法

在leveldb中,LRU算法的实现是使用两个双向环形链表，一个链表(in-use)存储当前正在使用的数据，另一个链表(lru)按照访问时间先后顺序存储缓存数据，每个数据都可以在in-use和lru之间切换。当我们需要使用LRU算法来淘汰数据时，只需要在lru上淘汰排序靠后的数据即可。

2.3 分片LRU缓存

分片LRU缓存很简单，其实就是同时创建多个LRU缓存对象，然后使用hash将特定的缓存数据放置到相应的LRU缓存对象中。这个方式可以避免一个LRU缓存中存储过多的数据。

三、详细分析

3.1 Hash Table

leveldb中实现了HashTable，使用的是最经典的数组+链表的实现。通过hash值定位到数组中的某一处，然后在这一处的链表上遍历查找。 HashTable的长度是哈希算法效率的最大影响因素，如果存在较多的hash冲突，则在链表上遍历查找的时间花费会很长。所以这个长度的选择是很重要的，比如在Java中的HashMap,实现中有一个负载因子0.7，如果数组上已经有值的数量超过总长度的0.7就会对整个哈希表resize。在leveldb中，这个resize的阈值是当前所有Insert进来的元素个数超过了数组的长度length，就会进行resize。这里简单的分析一下最重要的查找和resize过程。

• 哈希表查找过程

  // Return a pointer to slot that points to a cache entry that
  // matches key/hash.  If there is no such cache entry, return a
  // pointer to the trailing slot in the corresponding linked list.
  LRUHandle** FindPointer(const Slice& key, uint32_t hash) {
    LRUHandle** ptr = &list_[hash & (length_ - 1)];     //这里hash & (length_ - 1)会定位到小于length的位置,ptr就是hash到的位置
    while (*ptr != NULL &&
           ((*ptr)->hash != hash || key != (*ptr)->key())) {
           //hash到特定位置后，如果当前位置的hash和当前hash不一样，或者key不一样，并且指针也不为空，则继续向下找，直到找到
      ptr = &(*ptr)->next_hash;
    }
    return ptr;
  }

• 哈希表resize的过程

   void Resize() {
    uint32_t new_length = 4;        //哈希表的长度从4开始，逐倍增长
    while (new_length < elems_) {
      new_length *= 2;
    }
    LRUHandle** new_list = new LRUHandle*[new_length];
    memset(new_list, 0, sizeof(new_list[0]) * new_length);      //申请新的哈希表的所需的空间
    uint32_t count = 0;
    for (uint32_t i = 0; i < length_; i++) {    //将旧的哈希表的数据重新计算复制到新的哈希表中
      LRUHandle* h = list_[i];
      while (h != NULL) {
        LRUHandle* next = h->next_hash;
        uint32_t hash = h->hash;
        LRUHandle** ptr = &new_list[hash & (new_length - 1)];
        h->next_hash = *ptr;
        *ptr = h;
        h = next;
        count++;
      }
    }
    assert(elems_ == count);
    delete[] list_; //删除旧的哈希表
    list_ = new_list;
    length_ = new_length;
  }
};

3.2 LRUCache的实现

这里的LRUCache的私有成员变量包括以下几个

  // Initialized before use.
  size_t capacity_;         //LRUCache的大小。

  // mutex_ protects the following state.
  mutable port::Mutex mutex_;       //互斥变量，用来同步访问
  size_t usage_;                    //LRUCache已经使用的大小

  // Dummy head of LRU list.
  // lru.prev is newest entry, lru.next is oldest entry.
  // Entries have refs==1 and in_cache==true.
  LRUHandle lru_;                   //LRU链表的头，lru.prev代表新的节点，lru.next代表旧的节点，节点的refs == 1,in_cache == true

  // Dummy head of in-use list.
  // Entries are in use by clients, and have refs >= 2 and in_cache==true.
  LRUHandle in_use_;                //正在使用的节点链表的头，refs >= 2，in_cache == true

  HandleTable table_;               //哈希表，用来在缓存中实现快速查找

LRU的构造函数，直接构造出空的环形链表

LRUCache::LRUCache()
    : usage_(0) {
  // Make empty circular linked lists.
  lru_.next = &lru_;
  lru_.prev = &lru_;
  in_use_.next = &in_use_;
  in_use_.prev = &in_use_;
}

LRU中节点的引用和解引用

//增加引用时，如果在缓存中，则移动到in_use中
void LRUCache::Ref(LRUHandle* e) {
  if (e->refs == 1 && e->in_cache) {  // If on lru_ list, move to in_use_ list.
    LRU_Remove(e);
    LRU_Append(&in_use_, e);
  }
  e->refs++;
}

//解引用时会出现两种情况。1.节点不再需要，使用deleter来删除节点 2.不再被使用，移动到缓存
void LRUCache::Unref(LRUHandle* e) {
  assert(e->refs > 0);
  e->refs--;
  if (e->refs == 0) { // Deallocate.
    assert(!e->in_cache);
    (*e->deleter)(e->key(), e->value);
    free(e);
  } else if (e->in_cache && e->refs == 1) {  // No longer in use; move to lru_ list.
    LRU_Remove(e);
    LRU_Append(&lru_, e);
  }
}

缓存的插入

Cache::Handle* LRUCache::Insert(
    const Slice& key, uint32_t hash, void* value, size_t charge,
    void (*deleter)(const Slice& key, void* value)) {
  MutexLock l(&mutex_);

  LRUHandle* e = reinterpret_cast<LRUHandle*>(
      malloc(sizeof(LRUHandle)-1 + key.size()));    //这个地方申请内存需要注意，在LRUHandle中，key_data只有1个字节，其实是整个key的开头一个字节，所以申请的空间实际上是包含整个key的
  e->value = value;
  e->deleter = deleter;
  e->charge = charge;
  e->key_length = key.size();
  e->hash = hash;
  e->in_cache = false;
  e->refs = 1;  // for the returned handle.
  memcpy(e->key_data, key.data(), key.size());

  if (capacity_ > 0) {      //如果capacity大于0，也就是需要进行缓存
    e->refs++;  // for the cache's reference.
    e->in_cache = true;
    LRU_Append(&in_use_, e);
    usage_ += charge;
    FinishErase(table_.Insert(e));
  } // else don't cache.  (Tests use capacity_==0 to turn off caching.)

    //当使用的内存大于容量时，则要移除旧的缓存，直到缓存小于指定的容量
  while (usage_ > capacity_ && lru_.next != &lru_) {
    LRUHandle* old = lru_.next;
    assert(old->refs == 1);
    bool erased = FinishErase(table_.Remove(old->key(), old->hash));
    if (!erased) {  // to avoid unused variable when compiled NDEBUG
      assert(erased);
    }
  }

  return reinterpret_cast<Cache::Handle*>(e);
}

缓存的查找

Cache::Handle* LRUCache::Lookup(const Slice& key, uint32_t hash) {
  MutexLock l(&mutex_);
  LRUHandle* e = table_.Lookup(key, hash);      //直接借用哈希表完成缓存的快速查找
  if (e != NULL) {
    Ref(e);
  }
  return reinterpret_cast<Cache::Handle*>(e);
}

3.3 分片缓存的实现(ShardedLRUCache)

分片缓存的实现其实就是借助上面的LRUCaChe，只不过同时拥有多个LRUCache，然后特定的缓存数据会被缓存到相应的LRUCache中。

static const int kNumShardBits = 4;                     //可以理解为缓存片数量的容量因子(这里是4个bits，所以共有16个缓存片）
static const int kNumShards = 1 << kNumShardBits;       //一共有多少个缓存片

//通过Shard函数可以将任意一个hash分配到16个缓存片中的任意一个)
static uint32_t Shard(uint32_t hash) {
    return hash >> (32 - kNumShardBits);
}

所有的缓存存储和读取都会通过上面的Shard函数来找到特定的缓存片，从而实现了分片缓存。

五、总结

在这个部分，400行左右的代码就实现了哈希表，LRU缓存，分片LRU缓存。了解到LRU缓存的具体实现方式，特别是LRU中Ref和UnRef的实现非常精炼，很好的解决了一个数据在LRU缓存中被引用时脱离缓存，不使用时进入LRU缓存的功能。同时将LRU缓存简单的封装，就可以实现分片LRU缓存。