多进程+协程 (multiprocessing + gevent)

前面讲了为什么Python里推荐用多进程而不是多线程,但是多进程也有其自己的限制:相比线程更加笨重、切换耗时更长,并且在python的多进程下,进程数量不推荐超过CPU核心数(一个进程只有一个GIL,所以一个进程只能跑满一个CPU),因为一个进程占用一个CPU时能充分利用机器的性能,但是进程多了就会出现频繁的进程切换,反而得不偿失。

不过特殊情况(特指IO密集型任务)下,多线程是比多进程好用的。

举个例子:给你200W条url,需要你把每个url对应的页面抓取保存起来,这种时候,单单使用多进程,效果肯定是很差的。为什么呢?

例如每次请求的等待时间是2秒,那么如下(忽略cpu计算时间):

1、单进程+单线程:需要2秒*200W=400W秒==1111.11个小时==46.3天,这个速度明显是不能接受的

2、单进程+多线程:例如我们在这个进程中开了10个线程,比1中能够提升10倍速度,也就是约4.63天能够完成200W条抓取。
请注意,这里的实际执行是:线程1遇见了阻塞,CPU切换到线程2去执行,遇见阻塞又切换到线程3等等,
10个线程都阻塞后,这个进程就阻塞了,而直到某个线程阻塞完成后,这个进程才能继续执行,
所以速度上提升大约能到10倍(这里忽略了线程切换带来的开销,实际上的提升应该是不能达到10倍的),
但是需要考虑的是线程的切换也是有开销的,所以不能无限的启动多线程(开200W个线程肯定是不靠谱的)

3、多进程+多线程:这里就厉害了,一般来说很多人就是使用这个方法,多进程下,每个进程都能占一个cpu,
而多线程从一定程度上绕过了阻塞的等待,所以比单进程下的多线程又更好使了,例如我们开10个进程,
每个进程里开20W个线程,执行的速度理论上是比单进程开200W个线程快10倍以上的(为什么是10倍以上而不是10倍,
主要是cpu切换200W个线程的消耗肯定比切换20W个进程大,考虑到这部分开销,所以是10倍以上)。

还有更好的方法吗?答案是肯定的,它就是:

Nginx - Location 匹配规则

语法规则

location = /uri        = 表示精确匹配某个uri
location ^~ /uri       ^~ 表示精确的前缀匹配以uri开头的请求,优先级在正则之前
location ~ uri         ~ 表示区分大小写的正则匹配,这里的uri就是一个正则表达式
location ~* uri        ~* 表示不区分大小写的正则匹配,这里的uri就是一个正则表达式
location /uri          不带修饰符,表示精确的前缀匹配以uri开头的请求,优先级在正则之后
location /             通用匹配,未匹配到其他location的请求都会走到这里。 
                       其实就相当于匹配以/开头的请求,自然就能匹配全部

匹配顺序优先级

当存在多个同级location时,表达式越精确,优先级越高

例如:匹配http://localhost/wapabcd 时,/wap 优先级高于/wa

当存在多个不同级location时,匹配的优先级如下:

1、 =(完全精确匹配)
2、 ^~(带修饰符的前缀精确匹配)
3、 ~(区分大小写的正则匹配)
4、 ~*(不区分大小写的正则匹配)
5、 /uri(无修饰符的前缀精确匹配)
6、 /(通用匹配)

例子:

Linux命令之 chmod(改变文件存取模式)

命令格式

chmod [options] mode files

只有文件属主或特权用户才能使用该功能来改变文件存取模式。mode可以是数字形式或以who opcode permission形式表示。who是可选的,默认是a(所有用户)。只能选择一个opcode(操作码)。可指定多个mode,以逗号分开。

options:

-c,--changes
只输出被改变文件的信息
-f,--silent,--quiet
当chmod不能改变文件模式时,不通知文件的用户
--help
输出帮助信息。
-R,--recursive
可递归遍历子目录,把修改应到目录下所有文件和子目录
--reference=filename
参照filename的权限来设置权限
-v,--verbose
无论修改是否成功,输出每个文件的信息
--version
输出版本信息。

HTTPS 初步介绍

背景:

非对称加密:

基于数学方法,生成一个公钥-密钥对,来对数据做加密-解密,被公钥加密的数据只能被私钥解密,
同样,被私钥加密的数据也只能被公钥解密。所以可以用别人公开的公钥加密一段信息然后发送出去,
只有拥有对应密钥的那个人才能解密。但是缺点是加密-解密的计算成本高,比较占用cpu资源

对称加密:

和非对称加密相比,只生成一个密钥,加密-解密都用这个密钥,所以需要通信双方都拥有该密钥才能正常加/解密,
优点是计算成本低,加/解密速度比非对称加密快很多

HTTPS:

HTTP+SSL/TLS,本质上就是将原本由HTTP发送的明文通信内容,通过加密后发送,从而保证通信安全

CA:

全称:certification authority ,证书颁发机构。是权威、可信的机构,可以视作是HTTPS可靠性的基石

HTTPS连接建立过程:

* 客户端先预置CA的公钥(CA-pub.key),一般会是各浏览器自带,用户不关心

* 服务器生成公钥(SRV-pub.key),并将公钥和各种信息(公司、地址、国家、邮箱等)发送给CA做认证,CA认证通过之后会用CA自己的私钥(CA-pri.key)加密这些信息以及证书的hash值(hash-A),生成完整证书,返回给服务器,服务器自行保存。

Yii2中配置Redis并启用安全验证

1. 安装php-redis扩展:

下载phpredis扩展安装包:

wget http://pecl.php.net/get/redis-3.0.0.tgz 

安装phpredis:

tar zxvf redis-3.0.0.tgz  #解压
cd redis-3.0.0  #cd到解压后目录
/xxxx/phpize  #执行phpize
./configure  
make
make install

在php.ini中添加如下代码,启用redis扩展:

extension=redis.so


2. 安装yii2的Redis扩展:

cd /www/html/basic #cd到工程根目录下
PHP composer.phar require --prefer-dist yiisoft/yii2-redis #使用composer安装扩展