这个工作一直拖延了很久，终于有时间拿出来写写。
本文主要是根据“TIPI深入理解PHP内核”一书进行阅读和分析

一、概述

可以利用辅助的工具进行php代码阅读
例如vim或者sublimetext，重量级的可以用eclipse或者phpstorm这样的工具
本人用的是phpstorm进行代码阅读，CTRL+鼠标点击可以找到变量的定义位置，十分之方便

PG

1
2
3
4
5
6
7

#ifdef ZTS
# define PG(v) TSRMG(core_globals_id, php_core_globals *, v)
extern PHPAPI int core_globals_id;
#else
# define PG(v) (core_globals.v)
extern ZEND_API struct _php_core_globals core_globals;
#endif

PG用于定义或获取全局变量
ZTS是线程安全的标记

在main/php_globalsh中定义了宏PG和结构体_php_core_globals，用于存放一些常用到的全局参数
举例如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

struct _php_core_globals {
	······省略
    char *user_ini_filename;    //  用户的ini文件名
    long user_ini_cache_ttl;    //  ini缓存过期限制
    char *request_order;    //  优先级比variables_order高，在request变量生成时用到，个人觉得是历史遗留问题
    zend_bool mail_x_header;    //  仅在ext/standard/mail.c文件中使用，
    char *mail_log;
    zend_bool in_error_log;
    ········省略
};

入口文件

index.php

入口文件index.php中主要定义了一些全局路径变量如BASEPATH和APPPATH这种常用的变量
并且可以配置代码的部署环境，最后require真正的核心文件CodeIgniter.php

CodeIgniter.php

位于system/core/目录下，该文件是最主要的核心文件，他负责引入全局需要用到的一些关键的类，比如Common.php和Controller.php，这些类处于system/core目录下
CodeIgniter.php有点策略模式和工厂模式的意味了，很好的解决了代码耦合的问题，代码可拓展性很高，这也是我喜欢CI的一个地方
CI的异常处理机制是利用PHP的error_handler和exception_handler进行处理，实现代码如下：

1
2
3
4

//全局的异常处理都在这里进行
set_error_handler('_error_handler');
set_exception_handler('_exception_handler');
register_shutdown_function('_shutdown_handler');

这里的error_handler和exception_handler都是利用CI的Loader进行Exception类的实例化并且进行异常处理，同时Loader加载Log类进行日志记录

核心类库

Common.php

该文件定义了一些全局当中需要用到的函数，辅助框架运行，如is_cli()判断来判断是否cli运行环境

这里是实时更新的知乎数据用户分析地址：百万知乎用户数据分析

用户数据分析源码在这里：ZhihuAnalyse

爬虫项目源码放在我的github上：ZhihuSpider
爬虫代码分析可以看我的上一篇文章

喜欢的话帮忙点个star呗:-D

说个题外话：
今天下午的时候爬虫还在继续跑，知乎用户个人首页还用的是旧版
到了晚上7点发现爬虫居然爬不动了，十分疑惑，知乎个人中心竟然改版了，个人首页的url也改了，原来的爬虫用不了，
（不知道是不是知乎为了防止我爬数据做的措施，哈哈哈）
十分悲催，新版爬虫只能之后抽空出来再改一下了

效果图

项目源码放在我的github上：ZhihuSpider
喜欢的话帮忙点个star呗:-D

总体思路

1.首先是模拟登陆知乎，利用保存登陆的cookie信息
2.抓取知乎页面的html代码，留待下一步继续进行分析提取信息
3.分析提取页面中用户的个性化url，放入redis（这里特别说明一下redis的思路用法，将提取到的用户的个性化url放入redis的一个名为already_get_user的hash table，表示已抓取的用户，对于已抓取过的用户判断是否存在于already_get_user以去除重复抓取，同时将个性化url放入user_queue的队列中，需要抓取新用户时pop队列获取新的用户）
4.获取用户的关注列表和粉丝列表，继续插入到redis
5.从redis的user_queue队列中获取新用户继续重复步骤3

效果图

服务器带宽有限，并且知乎进行了ip封杀，所以这些数据也花了好几天的时间才爬下来
喜欢的朋友帮忙点个star呗♪(＾∀＾●)ﾉ ZhihuSpider

PHP内核中的HashTable原理

简易的结构

1
2
3
4
5
6
7
8
9
10
11
12
13

typedef struct _Bucket
{
    char *key;
    void *value;
    struct _Bucket *next;
} Bucket;
 
typedef struct _HashTable
{
    int size;
    int elem_num;
    Bucket** buckets;
} HashTable;

这个是一个简化过的哈希表结构
Bucket是一个链表，而_HashTable用于存储hash值并指向真正的数据储存单位

解决冲突算法DJBX33A

而链表是为了解决冲突用的，冲突解决采用DJBX33A算法，算法的内容如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

inline unsigned time33(char const*str, int len) 
{ 
     unsigned long hash = 5381; 
     /* variant with the hash unrolled eight times */ 
     for (; len >= 8; len -= 8) { 
         hash = ((hash << 5) + hash) + *str++; 
         hash = ((hash << 5) + hash) + *str++; 
         hash = ((hash << 5) + hash) + *str++; 
         hash = ((hash << 5) + hash) + *str++; 
        hash = ((hash << 5) + hash) + *str++; 
        hash = ((hash << 5) + hash) + *str++; 
        hash = ((hash << 5) + hash) + *str++; 
        hash = ((hash << 5) + hash) + *str++; 
    } 
    switch (len) { 
        case 7: hash = ((hash << 5) + hash) + *str++; /* fallthrough... */ 
        case 6: hash = ((hash << 5) + hash) + *str++; /* fallthrough... */ 
        case 5: hash = ((hash << 5) + hash) + *str++; /* fallthrough... */ 
        case 4: hash = ((hash << 5) + hash) + *str++; /* fallthrough... */ 
        case 3: hash = ((hash << 5) + hash) + *str++; /* fallthrough... */ 
        case 2: hash = ((hash << 5) + hash) + *str++; /* fallthrough... */ 
        case 1: hash = ((hash << 5) + hash) + *str++; break; 
        case 0: break; 
    } 
    return hash; 
}

哈希表结构

先看看哈希表的结构

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

typedef struct _hashtable { 
    uint nTableSize;        // hash Bucket的大小，最小为8，以2x增长。
    uint nTableMask;        // nTableSize-1 ， 索引取值的优化
    uint nNumOfElements;    // hash Bucket中当前存在的元素个数，count()函数会直接返回此值 
    ulong nNextFreeElement; // 下一个数字索引的位置，当数组成员没有指定键值时则采用该数字索引
    Bucket *pInternalPointer;   // 当前遍历的指针（foreach比for快的原因之一）
    Bucket *pListHead;          // 存储数组头元素指针
    Bucket *pListTail;          // 存储数组尾元素指针
    Bucket **arBuckets;         // 存储hash数组
    dtor_func_t pDestructor;    // 在删除元素时执行的回调函数，用于资源的释放
    zend_bool persistent;       //指出了Bucket内存分配的方式。如果persisient为TRUE，则使用操作系统本身的内存分配函数为Bucket分配内存，否则使用PHP的内存分配函数。
    unsigned char nApplyCount; // 标记当前hash Bucket被递归访问的次数（防止多次递归）
    zend_bool bApplyProtection;// 标记当前hash桶允许不允许多次访问，不允许时，最多只能递归3次
#if ZEND_DEBUG
    int inconsistent;
#endif
} HashTable;

PHP的GC（内存回收）机制就是根据nNumOfElements大小来进行判断，当采取unset()时，该字段的值减一，在字段值为0时进行内存回收
首先初始化HashTable的大小为8

1

requests.packages.urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='www.zhihu.com', port=443): Max retries exceeded with url: /people/claire-98-77/about (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7f2ee28c6588>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))

在调试的过程中，不断抛出该错误，在google查了很久，总结如下：
http的连接数超过最大限制，默认的情况下连接是Keep-alive的，所以这就导致了服务器保持了太多连接而不能再新建连接
解决方案：

解决一：
error trace is misleading it should be something like “No connection could be made because the target machine actively refused it”.

因为目标地址拒绝连接而产生的异常

1
2
3
4

try:
    page1 = requests.get(ap)
except requests.exceptions.ConnectionError:
    r.status_code = "Connection refused"

解决二：
more >>

介绍

利用该工具可以实现删除个人所有微博功能，不用受到第三方调用API次数限制
不能保证工具长期有效

GITHUB地址: https://github.com/kong36088/DeleteWeiboTool

使用方法

配置好代码根目录下的Config/config.php中要求必填的项目
$config['sina_cookie']：登陆好后，打开F12开发者工具获取REQUEST中的cookie值填入
$config['self_page_url']：打开开发者工具设置模拟IPHONE6访问页面m.weibo.cn,点击查看我的所有微博，复制页面URL

然后开始运行

cd /xxx/xxx/DelWeibo
php Delete.php

设置教程如下

epoll介绍

转自知乎

作者：蓝形参，Geek 伪技术宅

首先我们来定义流的概念，一个流可以是文件，socket，pipe等等可以进行I/O操作的内核对象。

不管是文件，还是套接字，还是管道，我们都可以把他们看作流。

之后我们来讨论I/O的操作，通过read，我们可以从流中读入数据；通过write，我们可以往流写入数据。现在假定一个情形，我们需要从流中读数据，但是流中还没有数据，（典型的例子为，客户端要从socket读如数据，但是服务器还没有把数据传回来），这时候该怎么办？

阻塞：阻塞是个什么概念呢？比如某个时候你在等快递，但是你不知道快递什么时候过来，而且你没有别的事可以干（或者说接下来的事要等快递来了才能做）；那么你可以去睡觉了，因为你知道快递把货送来时一定会给你打个电话（假定一定能叫醒你）。

非阻塞忙轮询：接着上面等快递的例子，如果用忙轮询的方法，那么你需要知道快递员的手机号，然后每分钟给他挂个电话：“你到了没？”

很明显一般人不会用第二种做法，不仅显很无脑，浪费话费不说，还占用了快递员大量的时间。

大部分程序也不会用第二种做法，因为第一种方法经济而简单，经济是指消耗很少的CPU时间，如果线程睡眠了，就掉出了系统的调度队列，暂时不会去瓜分CPU宝贵的时间片了。

为了了解阻塞是如何进行的，我们来讨论缓冲区，以及内核缓冲区，最终把I/O事件解释清楚。缓冲区的引入是为了减少频繁I/O操作而引起频繁的系统调用（你知道它很慢的），当你操作一个流时，更多的是以缓冲区为单位进行操作，这是相对于用户空间而言。对于内核来说，也需要缓冲区。

假设有一个管道，进程A为管道的写入方，Ｂ为管道的读出方。

假设一开始内核缓冲区是空的，B作为读出方，被阻塞着。然后首先A往管道写入，这时候内核缓冲区由空的状态变到非空状态，内核就会产生一个事件告诉Ｂ该醒来了，这个事件姑且称之为“缓冲区非空”。

但是“缓冲区非空”事件通知B后，B却还没有读出数据；且内核许诺了不能把写入管道中的数据丢掉这个时候，Ａ写入的数据会滞留在内核缓冲区中，如果内核也缓冲区满了，B仍未开始读数据，最终内核缓冲区会被填满，这个时候会产生一个I/O事件，告诉进程A，你该等等（阻塞）了，我们把这个事件定义为“缓冲区满”。

假设后来Ｂ终于开始读数据了，于是内核的缓冲区空了出来，这时候内核会告诉A，内核缓冲区有空位了，你可以从长眠中醒来了，继续写数据了，我们把这个事件叫做“缓冲区非满”

也许事件Y1已经通知了A，但是A也没有数据写入了，而Ｂ继续读出数据，知道内核缓冲区空了。这个时候内核就告诉B，你需要阻塞了！，我们把这个时间定为“缓冲区空”。

这四个情形涵盖了四个I/O事件，缓冲区满，缓冲区空，缓冲区非空，缓冲区非满（注都是说的内核缓冲区，且这四个术语都是我生造的，仅为解释其原理而造）。这四个I/O事件是进行阻塞同步的根本。（如果不能理解“同步”是什么概念，请学习操作系统的锁，信号量，条件变量等任务同步方面的相关知识）。

然后我们来说说阻塞I/O的缺点。但是阻塞I/O模式下，一个线程只能处理一个流的I/O事件。如果想要同时处理多个流，要么多进程(fork)，要么多线程(pthread_create)，很不幸这两种方法效率都不高。

Swoole的进程

Swoole中有几种进程，分别是：Manager、Reactor线程、Worker、TaskWoker
根据官方文档的介绍，分别介绍

Manager进程

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

Reactor线程

负责维护客户端机器的TCP连接、处理网络IO、收发数据
完全是异步非阻塞的模式
全部为C代码，除Start/Shudown事件回调外，不执行任何PHP代码
将TCP客户端发来的数据缓冲、拼接、拆分成完整的一个请求数据包
Reactor以多线程的方式运行