闲语杂谈 | 公交卡的工作原理

这个问题困扰了我很久了——公交卡是怎么工作的,或者说在使用公交卡的过程中数据是怎么流动的?根据数据存储位置来看,无非是分为卡内存储和中心服务器存储,公交卡的实现究竟是哪一种呢?

正常角度来考虑,卡中的余额肯定是存储在中心服务器的,但根据现实情况来看,无论公交车行驶到多么偏僻的地方,也无论刷卡人数的多少,刷卡过程都是瞬间完成的,全市有这么多公交车,中心服务器能无视物理环境而提供如此顺畅的服务吗?更何况还有更复杂的单点操作,比如当两辆公交车相会于站牌时,一乘客在短时间内从一辆车换乘到另一辆车,并迅速刷卡的处理逻辑,这种事务性问题对于中心服务器来说也会比较头疼。

以北京市为例,根据北京交通发展研究院的数据显示[1],北京市无轨交通日均客运量为一千万人次左右,按照一天运营10小时来算,平均每秒钟的客运量为接近300人,也就是说所谓的中心服务器需要承载300QPS的请求并且做到瞬时响应,如果严格来考虑的话,其实乘客的时间大部分是用在了乘坐,用在刷卡这个行为上的时间会更短,这样一来QPS肯定更高,更不要说还有BUG级别的早晚高峰了。换句话说,如果公交系统真的是实时连接了一个中心服务器的话,那么这个服务器相当于需要撑起一个千万日活的应用,而公交系统已经存续了很多年,远早于移动互联网的时代,这么看来数据存储在中心服务器似乎不太可能。

那么数据单纯存储在卡中是否可行呢?似乎可以解释刷卡响应速度和事务性问题了,但是这样一来,肯定有人尝试修改数据薅点社会主义羊毛,也不能真正投入使用。肯定还是需要一个中心服务器,或者需要一个去中心化的公交车互联系统(这条区块链的Idea值500个亿,加智能合约值1000个亿)。如果使用反证法的话,假设数据只存储在卡片中,那么北京交通发展研究院就无从得知全市公交车的日均客运量,那么上一段就写不下去,也就不会写到这一段,既然写到了这一段,说明假设不成立,即数据不可能单纯存储在公交卡中。

如果想实现公交车刷卡系统的话,可能需要权宜之计,即把中心服务器分为两层,外层是将近三万个[1]计算节点(公交车以及用于充值的地铁站),内层是真正的中心服务器(这条边缘计算的Idea值500个亿,加上云计算值1000个亿)。乘客在刷卡的时候只和当前公交车进行数据交换,同时数据也存储在卡中。公交车等待网络良好的时段或者定时与中心服务器进行数据交换,以此保证乘客数据的可靠性。在这个系统中,如果乘客单方面修改了卡片中的数据,那么等合账的时候肯定能发现没有这笔交易记录,直接把钱扣掉即可,这样也就没办法薅羊毛了。

公交卡信息系统架构设想
(图1:公交卡信息系统架构设想)

这个系统似乎已经可以解决上述的问题了,那么回头再来考虑公交车刷卡的场景,有一种非常常见的情况:下车不刷卡。对于下车不刷卡的情况,车上的广播会说“下车不刷卡,下次刷卡时将扣除最远里程无折扣票价”,其实这个提示已经告诉我们原理了,下次刷卡时扣除,说明此时下车后并未发生扣费,如果以后再也不刷卡,可能也就永远不会发生扣费。这种情况不可能是中心服务器来管控的,一来公交车与中心服务器的通信做不到实时,那么下车后迅速跑到另一辆车上刷卡就无法做到“扣除最远里程无折扣票价”了,二来如果真的是中心服务器来控制,也不需要等到下次刷卡时才扣费。如果要解决这个问题,另一个猜想是公交卡中不止存放余额信息,还存放着若干标志位,这种情况下需要一个“休想薅羊毛”标志位,上车置1,下车置0,此外还存储本趟车的最高票价,如果上车刷卡时发现“休想薅羊毛”标志位是1,那么就先扣完上一辆车的钱,再开始本辆车的扣款流程。

还有另外一种情况,从比较大的时间粒度来看,余额信息肯定是以中心服务器为准的,那么如果卡内信息出现了错误,无论是薅羊毛还是被薅羊毛,中心服务器的数据是在何时写入卡中的呢?上车刷卡时肯定是以卡内数据为准的,因为公交车不能知道是哪张卡要上车而提前从服务器获取数据,就算能提前获取,也不能保证此次数据获取之后到乘客上车之前没有发生后续余额变动。那么是不是下车刷卡时写入的呢?也不是,如果乘客只在车上呆很短的时间,公交车也不能保证在这段时间内完成和中心服务器的数据交换。那么是不是在充值的时候呢?这样也不行,如果羊毛收割者修改公交卡余额到2147483647元,那么往后余生也没有充值的必要了,服务器只能干瞪眼干着急就是没办法。这种情况我想不到有什么好的解释,暂时留白。

在翻找数据的时候,发现银行中也存在类似公交卡的脱机消费,银行卡的安全性肯定比公交卡更高,其中应该是涉及了比以上假设解释复杂得多的过程,需要翻翻论文才能找到正经的解释了。关于IC卡的安全和脱机消费的真正原理就暂时不挖掘了,留个坑下次再写。

参考文献

[1]. 北京交通发展研究院. 2018年北京交通发展年报[EB/OL]. http://www.bjtrc.org.cn/InfoCenter/NewsAttach/2018%E5%B9%B4%E5%8C%97%E4%BA%AC%E4%BA%A4%E9%80%9A%E5%8F%91%E5%B1%95%E5%B9%B4%E6%8A%A5.pdf. 2019/2019-03-27

专业学习 | 什么是图灵完备

坐公交车时突然想到 Brainfuck 这门语言,然后想到它是图灵完备的[2],之前一直靠这个词来装逼,然而细想好像说不清楚什么是图灵完备,于是翻了翻图灵完备的词条[3]。我们说一门编程语言是图灵完备的,意思是指它具有模拟图灵机的能力。另外还有一个相近的概念叫图灵等价,即如果两台计算机可以互相模拟,那么这两台计算机就是图灵等价的。

那么什么是图灵机呢,如果在现代计算机系统中去理解的话,就是具有循环和判断的能力、并且可以操作内存的系统,以下是维基百科上更为详细一些的解释[2]

图灵机从数学上描述了一个在纸带上操作的机器。纸带上有一个个符号,机器可以读写这些符号。图灵机的操作由一个有限指令集集合定义,比如“在状态42,如果当前符号是0,那么就写入1;如果当前符号是1,那么就进入状态17,如果此时看到的符号是0,那么就写入1并且将状态转换成6” 。更精确地说,图灵机由以下部分组成:

  1. 一条被分成一个个小格子的纸带,每一个小格子都包含一个有限字符集中的符号,该字符集中还有一个特殊的空白符。这条纸带可以任意向左或者向右延长,在一些理论中,这条纸带只能向右延伸,不管怎么说,纸带总是足够使用
  2. 一个位于纸带上方的读写头,它能够读写下方小格子中的符号,每次读写头可以向左或者向右移动一个格子(有的模型中是读写头固定,纸带移动),也可以不动
  3. 一个存储图灵机当前状态的状态寄存器,在图灵机运行之前,状态寄存器中是特殊的起始状态
  4. 一个有限的指令表,假设当前图灵机的状态是$q_i$,读写头下方的符号是$a_j$,该指令表可以控制图灵机依次执行以下操作:
    1. 写入或者擦除当前的符号(用$a_{j1}$替换$a_j$)
    2. 移动读写头,向左向右或者保持不动
    3. 保持当前状态或者进入下一个状态(从状态$q_i$进入状态$q_{i1}$)

从这个角度去看,图灵完备对于一门编程语言来说并不是特别难以达到的目标。实际上,目前我们能接触到的编程语言中,只有一些DSL是非图灵完备的,如HTML、CSS、SQL等[4]。在所有的图灵完备语言中,最简单的就是Brainfuck[1],它只有8种运算符,其编译器也只有200多个字节。虽然看起来很Braing Fucking,但是理论上它确实可以完成任何一门编程语言的工作。以下是它的8种操作和对应的C语言:

操作 C语言
> ++ptr;
< --ptr;
+ ++*ptr;
- --*ptr;
. putchar(*ptr);
, *ptr = getchar();
[ while (*ptr) {
] }

如果用Brainfuck来写”Hello World”的话,代码差不多是下边的样子:

1
2
3
++++++++++[>+++++++>++++++++++>+++>+<<<<-]
>++.>+.+++++++..+++.>++.<<+++++++++++++++.
>.+++.------.--------.>+.>.

图灵机的一个特点是其无法判定停机问题[5]。停机问题定义很简单,即是否能找到一个程序,它可以判定任意一个程序是否可以在有限时间(步数)内结束运行。停机问题是一种自我指涉问题,类似的还有经典的理发师悖论,“我只给不给我刮胡子的人刮胡子,那么我给不给我自己刮胡子?”。

这个问题的证明也很简单,假设程序P对于任意输入I都可以判定其是否停机,如果停机就输出1,否则输出0,那么现在给出另外一个程序F,它在内部调用了P,并且以自身作为输入,即F(F),如果F停机,即P(F)输出1,那么F(F)就无限循环;如果F无限循环,即P(F)输出0,那么F就立刻停机。构成了矛盾的状态,因此可以判定程序是否停机的程序P是不存在的。

参考文献

[1]. Wikipedia. Brainfuck[EB/OL]. https://en.wikipedia.org/wiki/Brainfuck. 2019-03-19/2019-03-26

[2]. Wikipedia. Turing machine[EB/OL]. https://en.wikipedia.org/wiki/Turing_machine. 2019-03-05/2019-03-26

[3]. Wikipedia. Turing completeness[EB/OL]. https://en.wikipedia.org/wiki/Turing_completeness. 2019-03-16/2019-03-26

[4]. yannis. Are there mainstream general-purpose non-Turing complete languages available today?[EB/OL]. https://softwareengineering.stackexchange.com/questions/202488/are-there-mainstream-general-purpose-non-turing-complete-languages-available-tod. 2013-06-24/2019-03-26

[5]. Wikipedia. Halting problem[EB/OL]. https://en.wikipedia.org/wiki/Halting_problem. 2019-03-05/2019-03-26

咪蒙事件反思录

就在昨天(2019.02.21),咪蒙的微信公众号正式注销。

事情还要从年前的一件事说起,咪蒙旗下的公众号“才华有限青年”发布的《一个寒门状元之死》在朋友圈广泛传播,并在新浪微博引发了舆论反弹,这篇文章随后被迅速删除。这种文章跟知乎上的一大票“说说我的一个朋友”一样,看两眼晕车的感觉就上来了,也无怪大家会骂得那么惨。在2月1日,咪蒙团队发布道歉信,宣布微信公众号停更两个月,微博永久停更。咪蒙终于被自己的月薪5万的实习生坑了,就算不是这个实习生,也有下一个来坑。

咪蒙在微博永久停更,但是微信只是停更两个月,说明了咪蒙想要暂避风头,之后再接着卖自己的毒鸡汤,毕竟微信圈子封闭,喜欢她的自然也会继续喜欢她。但是时隔仅20天,微信公众号就注销了。账号是主动注销的吗?是的。是因为咪蒙良心发现而注销的吗?你猜。联想最近从吴秀波、翟天临事件中透露出的对于明星群体的容忍度收紧,背后到底发生了什么就留给诸位看客品味了。

咪蒙该不该得此下场?该。这事往大了说,就是某种程度上的发国难财,社会本就焦虑,没能给出正向引导,反而还唯恐天下不乱,在输出负面价值观的过程中赚得盆满钵满,留下了原地傻笑的人群。有人说咪蒙引发了全社会的一系列焦虑,比如对于熊孩子的厌烦,对于“直男”的轻视,还有那篇当时我也非常赞同的《致贱人:我凭什么要帮你》。然而这是太看得起咪蒙了,咪蒙在这些事件中的角色就和杨乐多在咪蒙风波中的角色一样,只是赶上她了而已,没有她也有别人。整个社会的焦虑值本来就是处在一触即发的满条状态的,咪蒙只是发现并推了一把。但既然你推了,被抓住裤脚一起带下山崖也不是什么意料之外的事情

在这件事发生之后,很快就出现了一些如“咪蒙倒了,但是我并不高兴”之类的理中客的声音。大意都是相同的,说白了就是“我不赞成你的说法,但我誓死捍卫你说话的权力”,咪蒙输出负面价值观是不对,但是不能一刀切,就连头部的声音都如此轻松随意地拿捏,我们之后还有什么思想自由的可能。然而事实真的如此吗?咪蒙的错误可不只是乱说话,作为大众性的KOL,她的错在于没能正确行使自己的权力,既然如此,引入公权力进行制裁是非常合理的,一如当年的卢本伟,这已经不只是“我可以骚,你不能扰”的程度了,骚得太过了。咪蒙的错是实实在在的,至于透露出的潜在的更多的信息,现在还是空谈,也只能是空谈。

从另一个角度来说,咪蒙被封杀和吸毒艺人被封杀,和杀人犯被执行死刑有何区别呢?都是公权来审判,公权来执行,若是人人自危,也应该首先自危自己的命其实不在自己的手里。为什么大家不这么想呢?亚当斯早就给出了答案:“任何在我出生时已经有的科技都是稀松平常的世界本来秩序的一部分;任何在我15-35岁之间诞生的科技都是将会改变世界的革命性产物;任何在我35岁之后诞生的科技都是违反自然规律要遭天谴的”。有很多国家废止了死刑,原因和理中客们是一样的,在强大的公权和个体之间,为了保证公平,需要偏袒弱小的一方,也就是说其实大家并不否认罪犯该死,只是想帮帮自己臆想中这个小可怜罢了。然而很遗憾,这不是过家家,既然犯了这么重的罪,就该受这么重的罚

咪蒙下场如何其实并没有所谓,我们应该反思的是这件事情透露出的一个事实:我们习以为常的东西对于局外人来说可能是颠覆三观的。比如无死刑国家的人可能无法理解死刑,虽然我们看到的一些国外的声音很多都提及“你看看人家中国有死刑多好”,但是请注意,这是被筛选之后的言论,英国民主的群众们说脱欧就真的脱欧了,《欧洲人权公约》是怎么通过的还用多想吗?另外我们也可能是自己的局外人,这样的事件近年来发生了非常多,咪蒙只是其中一个并不算大的而已。

咪蒙事件也好,翟天临事件也好,甚至是《流浪地球》现象也好,类似的事情可能会越来越多,趋势是你我无法左右的,事情也本就不存在简单的善恶两面性,唯一能做的就是改变和适应,闷声发大财才是最好的

古法编程 |『五星出东方利中国』锦护膊的前世今生

文中图片和部分描述来源于BiliBili《国家宝藏》节目

又是一个忙碌且清闲的周末,晚上刷B站打开了《国家宝藏》节目,最近更新的是第二季第六集,讲述的是新疆维吾尔族自治区博物馆的三件馆藏。这一期的节目相对来说没有前几期搞笑或者煽情,而且太师不怎么露面(笑)。当看到了最后一件馆藏文物时,发现这个是知乎上被吹爆的『五星出东方利中国』锦护膊,而且守护人还是我非常喜欢的蓝天野老爷子,所以顿时来了兴趣开始往后看。

国宝正面

就像杭州博物馆馆藏的战国时期的水晶杯一样,如果摆在地摊上看起来也就值5块钱,但是当得知这些东西是来源于千年以前的时候,就会产生一种恍如隔世的感觉,它们正因为看起来太过寻常,所以才在经历了千年催化后带来了厚重的历史感。不过就像对待其他文物一样,刚开始我认为这件文物的当代价值在于其背后绑定的历史,而制造工艺的附加于其上的价值只在遥远的过去才有用。

在节目后期的现代故事中,节目组请到了中国丝绸博物馆的赵丰馆长为大家讲解千年前织机以及这件锦护膊的复原过程。在提到这件织机的时候,节目组称其为“中国古代的计算机”。乍听之下感觉有些膈应,我一向不喜欢强行把当代所有的概念都和古人的所作所为绑定在一起,比如什么伏羲女娲结合象征DNA双螺旋结构之类(节目组中虽然称这是一个巧合,但是把两样东西这么暧昧地塞到一块绝对会让一些人产生盲目的误解)。但是听到后来我才发现这件织机对得起“计算机”的称号,并且也加入到了“奈何老夫没文化,一句卧槽行天下”的大军中。下图是这件织机刚出土和复原之后的样子。

织机出土

织机出图

因为这件锦护膊上有复杂的图案,一开始对于原理的猜测是把一根纬线一段段染成不同颜色,然后把多根纬线怼到一起拼成的,但是看到了原理讲解之后,我才发现古人真的是无比智慧。其中确实用到了类似二进制编码的概念,而且并非是把程序烧录到ROM中,而是真正的可编程。下边组图是节目中对于原理的讲解。

织机原理

织机原理

织机原理

织机原理

织机原理

织机原理

织机原理

对于我们熟知的一副像素图片而言,其中的每个24位深像素的颜色的都是由RGB三种颜色的数值组合在一起决定的,比如#3C4B6A这个颜色代码表示红色的数值是3C,换算成二进制就是0011 1100,这几个二进制的数值决定了红色的存在感有多强,在这件织机中,它使用的可以认为是5位深的像素编码格式,每一个像素点由5根经线和1根纬线共同决定,假如经线的颜色从左到右依次是蓝色、绿色、红色、黄色和白色,那么如果纬线把除了绿色之外的其他四根经线压下去,这个像素点就呈现出绿色,其他颜色同理,这样经过多达84片综(梳理丝线的工具,好像也是“综合”一词的起源)的不断调整来控制多达840,000个像素点的颜色,最终才得到了这件珍贵的国之珍宝——『五星出东方利中国』锦护膊。

织机原理

古人的智慧由不得你不服啊。当然具有智慧的不只是古人,今人在复原文物的过程中肯定也贡献了很多奇思妙想,没有他们的努力,古人的智慧也早就消散在千年的岁月中了。《国家宝藏》是蛮好的一个节目,能让人爱看,能让人看进去,不是靠苍白的说教,而是靠讲诉故事,靠平等的交流,靠古人跨越时空的倾诉,靠情感上的共鸣,真正引发观众的民族自豪感和爱国热情,把历史的灰尘从文物上抹去,赋予了它们新生。

JMeter 使用笔记

安装配置

安装配置

需要安装Java,尽量使用Java SE 8以上的版本。添加把JRE和JDK添加到环境变量中。

JMeter安装

JMeter官网下载相关版本的JMeter链接,直接解压即可。注意要把JMeter的根目录添加到环境变量JMETER_HOME中,之后集群测试会使用到。

单机测试

单机测试主要分为两个大的步骤,一个是添加线程组和Http请求,另一个就是添加Listener来查看测试结果,网络上有很多现成的教程,这里就不再赘述。

集群测试

集群测试很简单,只要把Slave机器部署好,Master会把测试脚本发送给Slave进行测试,部署过程也可以参考这篇文章。具体部署步骤如下:

  1. 在每台Slave上都安装配置好单机环境

  2. 在Slave上修改$JMETER_HOME/bin/jmeter.properties文件,主要修改以下几部分(1099为JMeter服务器默认端口)

    1
    2
    3
    server_port=1099
    server.rmi.localport=1099
    server.rmi.ssl.disable=true
  3. 在Master上修改$JMETER_HOME/bin/jmeter.properties文件,主要修改以下几部分,如果想要在Master上也运行测试程序的话,可以把以上Slave的配置也加到Master里,并且在remote_hosts中添加localhost:1099的项

    1
    2
    # 10.0.0.X为Slave的IP
    remote_hosts=10.0.0.1:1099,10.0.0.2:1099

完成了以上工作,在Master上启动测试程序(运行->远程启动所有)即可开始集群测试。这种模式下有一个非常大的缺点,就是各个Slave的测试结果会实时发送到Master上,对Master的网络和CPU都造成了很大的压力,如果能够积累一定的数据之后批量发送会好很多。也可能是我没有找到正确的使用方法,如果有解决方案,还请不吝告知。

常见问题

Http Post请求该怎么发

Post请求的Body在编程语言层面有很多的叫法,什么Payload、Data、Params、KWargs之类,在JMeter的Http请求界面,选中Method为POST之后,下边的参数栏有三个Tab,分别是Parameters、Body Data以及Files Upload,因为在GET请求时是使用的Parameters,所以这里一上来就往Body Data里填数据。但是当Content-Type为multipart/form-data,并且同时发送参数和文件的时候,在Body Data里填写的参数会被Files Upload的内容覆盖掉。所以至少在这种情况下需要把请求体中的参数填到Parameters栏里。

在其他Content-Type中尚未见到这种限制,比如application/json时就可以直接把Json对象填入到Body Data中。

表单请求无法正常发送

当Content-Type为multipart/form-data,并且同时发送参数和文件的时候,可能请求无法成功发出去,如果其他工具(比如Postman)可以正常发送请求,那么应该是JMeter实现的问题,在Http请求的Advanced标签中把Client implementation换成Java即可解决这个问题。

集群运行时报找不到rmi_keystore.jks错误

因为JMeter集群在运行时默认会开启SSL,所以需要额外进行SSL的配置,如果想要跳过SSL直接使用,需要在jmeter.properties中设置以下内容

1
server.rmi.ssl.disable=true

电影时评 | 白蛇·缘起

世间两条腿的恶人多得是,长了条尾巴又如何?

昨天晚上无意间在微博刷到了这部电影的官博,惊异于宣传片的高质量,更惊异于制片方在宣传上寥寥无几的投入。因为被坑习惯了,所以一开始觉得这部片子可能只是金玉其外,翻了翻官博的推文,发现评论是一边倒的好评,其间夹杂着对官方疲软宣传的抱怨。在一些社区中你会发现“自来水”们的画风都是下边这样的…

只要你去看《白蛇·缘起》我们就是一辈子的朋友

上次见到这种阵仗还是2015年《大圣归来》的时候,无论是微博还是B站都是铺天盖地的自来水。但是随着《大圣归来》电影的上映,评论开始回落,社区也出现了一些更为详实和客观的评价,甚至有诸如LexBurner的“一坨狗屎”之类的纯负面标签。

那么《白蛇·缘起》到底如何呢?没有调查就没有发言权,于是大晚上又跑到电影院赶了个晚场,看完了这部片子,难得的非子供向商业片。就画面上来说,下边这张图就可以代表整部电影的质量了。

《白蛇·缘起》主题MV片段

整部片子的故事线很简单,和白蛇传没有太大的关系,片名中的“缘起”也点明了这是一部前传性质的作品。神来之笔在片尾的彩蛋中,500年后,许宣转世成了许仙,在断桥邂逅小白和小青,伴随着《青城山下白素贞》的旋律,500年的思念和痛苦烟消云散,尽化作那一撇浅浅的笑。

结尾彩蛋

《白蛇·缘起》和《大圣归来》之间是有很多的相似之处的,无论是质量上乘的画风(至少在主角的刻画上舍得花钱)还是家喻户晓的IP都赢得了大量的好评。有人说这是在卖情怀炒冷饭,但是有上千年积累的情怀和冷饭为啥不用呢?就像余潇洒所说,“入宝山空回,这不是勇敢,而是愚蠢”。两者的相似之处还在于单薄的剧情上,节奏前慢后紧,画面和音乐上的优势被内容抹消了不少。这是需要改进的地方,承认,然后正视,就会越来越好。

然而两者很有可能面临不同的命运。

相比于《大圣归来》10亿的票房,《白蛇·缘起》目前首周票房只有5000万左右,全片制作成本接近1亿,票房分成约为1/3,也就是说3个亿的票房才能保证不亏本,照这个趋势下去又将成为一个血本无归的典型。《大圣归来》不只有精良的制作,还有强大的宣发,能引起大范围的讨论热潮,票房就算不破纪录也能收回成本。反观《白蛇·缘起》的制片方,到现在也只是不温不火地发几条微博,连个热搜都没买,简直气得人肝疼。

《白蛇·缘起》实时票房

一方面是焦急的粉丝,一方面是没有什么动作的官方,这是一种略显滑稽的场景。片方显然不傻,那么现在唯一的解释就是——没钱了。互联网没有让推广更便宜,只是让推广费花得更快而已。或许追光动画在制作的时候留出了宣发的预算,但是随着制作成本的扩张,这部分预算也不得不投入到制作中。不过,从票房趋势中也可以看到希望,虽然净票房的增长被工作日截断,但是在排片基本不变的情况下,票房占比是在提升的,希望到周末能看到转机的来临。

从几年前起,国漫崛起的呼声就不绝于耳,从那之后也确实出现了很多好看的片子,大家忽然发现原来老祖宗留下了这么多好东西,有这些还担心什么文化入侵。但是另外一个可悲的现实是,这些片子连收回成本都成了一种奢望,在一次又一次现实的打击之下,满怀热情的投资人和制作者是否还有勇气开始下一个项目呢,我们不知道。

但是我们可以给出答案。

关于计算机学习

我认为计算机领域真正的学习应该是“博客式”的,即遵循“遇到问题->查阅资料->弄懂问题->有成就感->总结记录”,早些时候我把这个叫做“需求驱动学习。

举个例子

嘟嘟(我家泰迪)平日里自诩Java小王子,无论是手写Runnable还是一口气1 << 8个线程池都信手拈来。有天老板(我)在微信上说:“大家都说‘人生苦短,我用Python’,蟒蛇听起来比咖啡厉害多了嘛,你,赶紧用Python把后台重写一遍”,嘟嘟一边暗自庆幸老板还没听说过PHP,一边嘀嘀咕咕开始了改造之路。在迁移Java的多线程部分的时候,嘟嘟想用Python的Thread来做,但是发现Python中有万恶的GIL(Gay In Love Global Interpreter Lock),想要实现走位酷炫的线程池的计划泡汤了。

一些社区建议使用多进程来代替多线程,但是嘟嘟在写了两个Demo之后发现它们和多线程不一样,变量竟然不能共享,这代码还怎么写,于是继续面向百度编程,在误点进去十几个培训机构的主页之后,嘟嘟终于找到了一个新奇的解决方案——异步编程。在短暂纠结于yield和yield from的写法之后,嘟嘟又找到了更好用的async/await,并顺利把Java上的多任务移植到了Python上。好景不长,有天嘟嘟不小心让视频转码的任务读入了硬盘深处700多个G的马克思主义视频教程,发现Python的其他多任务都不能正常响应了。在妙峰山烧了七八柱香之后,嘟嘟才了解到原来是因为一个异步任务被阻塞住了,导致很多其他任务不能被处理。最终嘟嘟还是把计算密集的任务扔到了多进程上去做。

在整个项目迁移结束之后,嘟嘟开始对迁移过程进行复盘,发现以下几点需要搞明白:

  1. 为啥多进程变量不能共享
  2. 为啥有GIL在多线程就不好用了
  3. 为啥一个异步任务阻塞会影响其他任务
  4. 为啥在百度搜Python老蹦出来培训机构

于是嘟嘟开始了新一轮的调查研究,在经历过以往的教训之后,嘟嘟学会了在一个404的网站上搜索404的信息。这才明白了进程和线程的关系,明白了进程如何通过消息队列进行通信,明白了异步编程的好处和局限性以及事件循环的原理。无论是进程、线程、协程还是纤程,本质都是想要达到一个目的,即“在需要的时候占用CPU,不需要的时候释放CPU”。找了一堆的资料之后,嘟嘟又打开了大学时崭新的操作系统课本,把处理器这一章从头读了一遍,发现醍醐灌顶,每一句都是好东西,感叹自己当时上课怎么就没发现这本书的精妙之处。感慨之余,决定把自己的感受记录下来,标题就叫《关于计算机学习》。

我的经历

从本科一年级第一节编程课开始,我就喜欢上了编程。之后整个一年级都沉浸在ACM刷题和囫囵吞枣的学习之中。虽然当时只会命令行编程,但是还是做出了一些小玩意,比如自动计算游戏中交易的收益、收集名侦探柯南TV版的分集信息等,当时没什么备份的概念,也不懂版本控制,现在程序都遗失了,留下来的只有一个基于MFC的计算器。

我的专业是计算机科学与技术,当时要学习一些计算机的基础课,比如操作系统、数据结构、计算机组成、计算机网络、编译原理、数据库等,在大学前两年中,我一直都特别讨厌这些科目。一边是自由新奇的编程实践,另一边是枯燥和看似无用的琐碎知识点——就像高中一样,显然后者无法引起任何人的兴趣——即使有,在一个具有强实践性质的专业中谈纯粹在课本中获得的快乐也和耍流氓无异。当时在这些课程中我相对不那么讨厌的是数据结构课,因为其中的很多算法我在很久之前就已经在POJ上刷过很多次了,所以上课的时候有一种仅通过预习无法感受到的亲切感——这也是本文想要传达的观点。

我是什么时候有了“还是制定专业课计划的那几个老头厉害,是我当时太年轻了”这种想法呢?在大二结束和大三开始这段时间,随着写代码越来越多,接触的领域越来越多,我开始做了一个在当时看来算得上是巨无霸的项目,从前端到后端都是我一个人完成。和我之前接触的项目不同,这个项目是真的有很多用户的(笑),所以系统上线之后不断暴露出越来越多的问题,比如数据库查询很慢,比如网络延迟很高,比如客户端卡顿等。在给自己收拾烂摊子的时候,开始重新学习了多线程、数据库、计算机网络(主要是退避算法之类),然后猛然惊觉,“这不就是我大学里的专业课么?”。

时间一晃到了现在,我已经研二了。在给师弟师妹们介绍我那点不成器的经验时,我的观点也从“多实践多编程”转变成了“先把基础打好”。计算机科学与技术的专业课都很重要,无论讲课的老师水平如何,都一定要学好,它们是构造整个互联网空间的基向量。话虽如此,这并不代表我完全同意目前计算机教学的思路,我认为计算机领域真正的学习应该是“博客式”的,即遵循“遇到问题->查阅资料->弄懂问题->有成就感->总结记录”,早些时候我把这个叫做“需求驱动学习”。

我的观点

为什么我们都不爱听大道理?为什么我们听了那么多道理仍然过不好这一生?为什么我们反感鸡汤?

我认为计算机的这些基础课就像所谓的大道理一样,没有相关的经历作为培养基的话是无论如何也不可能理解的,自然只能觉出枯燥无味和腐朽陈旧来。但是倘若踩过了无数的坑就会明白,这些基础课本字字珠玑,毫不过时(也可见我们的科学发展其实并没有大家想的那么快),古人诚不我欺也(有多少人都写成“诚不欺我”,意思还是一个意思,但是对话场景瞬间从项脊轩蹦到了王老大烧烤摊)。想要理解多少大道理就要踩多少坑,该踩的坑一个都少不了。

不要误会,我不是在宣扬基础教学无用论,我的意思是初学者一开始不必过于深入地了解基础知识,因此此时无法真正理解,不如先拓宽知识面,暂时了解有这么回事就可以,把一部分的时间匀出来自己去折腾,只要智力正常并且适合干这行,很快就会产生深入学习的需求的,这时候的学习效率远比按部就班划拉书本要高很多。以嘟嘟来举例,学习处理器调度的过程可以分为以下几个阶段:

  1. 了解到一切计算都被分解成指令交给处理器顺序执行
  2. 在Bilibili上自动监测赶海四天王的视频,并及时下载
  3. 查阅类似实现的开源代码,学习,重复踩坑,完成需求
  4. 查阅课本或工具书,学习进程和线程的原理、关系以及区别
  5. 拓展了解协程、纤程、Actor等异步编程模式
  6. 接触NodeJS、Python、C#、GoLang在多任务上的做法,对比学习
  7. 感觉自己很厉害,写博客交流学习,一写笔才发现还有很多细节不懂,继续学习
  8. 开始踩下一个坑……

以上只是一个捏造的例子,用来说明一个渐进式的学习过程可能是什么样子的,实际过程中的步骤或许没有这么精细和繁琐,但大步骤不会差很多。我可以保证相当程度的低年级计算机专业同学对于以上的这些东西都没有清晰的概念,所有东西都糊作一团。根据我浅薄的经历来看,有一些经验比较丰富的同学可能只是停留在前三个阶段,实事求是地讲,代码风格和注释都很漂亮,但是就是无法再往前一步。顺便一提,还有一些同学在学习某些语言或者框架时,总是会虔诚地走完“买书->找视频->进技术群”这个流程,我认为这样效率是比较低的,有那百度云下载视频的时间官网文档都看了好几遍了。不如先找个点切入,即使是Hello World,然后一步步拓宽把整个需求盘下来,在复盘的时候再通过书或者是视频系统学习。系统学习应该是后置的,连它能干嘛都还不知道,系统学习又有什么用呢,结果只能系统地遗忘。至于技术群,其作用是收表情包,和技术没啥关系。

无论需求从哪里来,是随便玩玩,还是饭圈妹子的抢票委托,还是老板或外包的要求,只要你决定实现一个需求,下一步就是分析和调查需求应该怎么实现。如果你有一定的基础知识(即使是广泛而不深入的),那么调研的过程会更有针对性,接下来就开始”Done is better than perfect”的过程,其间随着踩坑会开始接触相关领域的知识,然后拓展学习总结出一套敝帚自珍的宝贝,在成就感和虚荣心的驱使下,把这些碎碎念记录下来,记录的过程发现原来还有很多细节自己根本没弄清楚,再去迭代学习,一步步把这篇博客写完。基础知识在这个过程中会一步步得到加强,每一次都是重新认识,每一次的认识都更加清晰几分。

或许你又会问,总是实现一个又一个大同小异的需求,如何才能摆脱成为CRUD Boy的命运呢?多想,多拓展,多总结记录,并乐在其中,It’s that simple.

在服务器上搭建 Jupyter Notebook

Jupyter Notebook

安装Jupyter

假定工作目录为/home/jupyter

1
2
3
$ virtualenv venv -p python3
$ source venv/bin/activate
$ (venv) pip install jupyter

配置Jupyter

安装Jupyter之后,在~/.jupyter下查看是否存在jupyter_notebook_config.py文件,如果没有,就使用

1
$ (venv) jupyter notebook --generate-config

命令生成配置文件,Jupyter的具体配置内容参见Jupyter Notebook的配置选项,下边的几个选项是为部署在服务器上可能要用到的(下边c.NotebookAPP.password的设置方法见Jupyter Notebook添加密码

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# Nginx访问时会出现跨域访问,需要在这里允许
c.NotebookApp.allow_origin = '*'
# 禁止随意修改密码
c.NotebookApp.allow_password_change = False
# 是否允许远程访问
c.NotebookApp.allow_remote_access = True
# 访问URL,假定我们想通过`$HOST/python`来访问
c.NotebookApp.base_url = '/python'
# 访问之后跳转的URL(自定义),要加上base_url
c.NotebookApp.default_url = '/python/tree'
# Jupyter Notebook Server监听的IP
c.NotebookApp.ip = '127.0.0.1'
# Jupyter Notebook的工作目录,用于限制访问位置
c.NotebookApp.notebook_dir = 'data/'
# 启动Jupyter Notebook之后是否打开浏览器(服务器上此选项应该关闭)
c.NotebookApp.open_browser = False
# 客户端打开Jupyter Notebook的密码哈希值
c.NotebookApp.password = 'sha1:******'
# Jupyter Notebook Server监听的端口
c.NotebookApp.port = 8888

集成 Nginx

Jupyter Notebook使用tornado作为服务器和Web框架,如果想要获取更高的性能以及灵活性,可以使用Nginx作为代理服务器。在/etc/nginx/conf.d/jupyter.conf中添加以下内容:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
server {
listen 80 default_server;
server_name myjupyter.com;
charset utf-8;
client_max_body_size 75M;

location /python/ {
# 这里要和Jupyter配置中的Base Url一致
proxy_pass http://127.0.0.1:8888/python/;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
# 因为用到了Websocket协议,所以下边的配置是必须的
proxy_set_header Connection "upgrade";
proxy_redirect off;
}
}

配置完成之后,启动Jupyter Notebook即可远程访问

1
2
3
4
# 直接运行,测试使用
$ (venv) jupyter notebook
# 后台运行
$ (venv) nohup jupyter notebook &

此时在浏览器输入http://myjupyter.com/python即可进入Jupyter Notebook。

Python异步编程

异步编程

在Python中,由于CPythonGIL限制,不能使用多线程充分利用资源,因此在进行诸如文件存取、网络请求等IO操作的时候极其浪费资源,程序往往要在一个点上空等。虽然Python可以借助多进程来改善,但是进程相比线程来说过重,如果只用多进程就可以完全解决问题,线程这个概念也就不会出现了。

在耗时任务(主要是IO)的操作上,Python提供了一些方法来解决,比如协程的概念。初次了解协程的时候认为这是可以拯救世界的东西,概念新颖,方法独特,但是在了解了如C#的async/await以及Javascript(同样是单线程语言)的async/await之后,明白了基于yield/send的协程仍然使用起来仍然不够顺手。

Python3.4版本之后,Python引入了asyncio标准库,使用@coroutineEventLoop可以更方便地完成Python协程的工作,接着在Python3.5中,Python引入了async/await关键字,彻底简化了Python异步编程流程。自从C#最早提出async/await之后,很多语言都引入了这一机制,因为它真的太好用了,可以完全以同步的风格进行异步编程。不过由于与C#的实现机制不同,在Python协程中仍然有一些具体的细节无法回避,比如send/yield的交互。

工具对比

在Python生态系统中,有很多异步编程库可以使用,这些编程库有的是诞生于Python异步支持之前,自行实现了事件循环,有的是依托于Python的异步机制进一步开发,在进行异步编程的时候,可以借助以下的工具来简化工作:

  • gevent:自己实现了时间循环,很早的异步处理库
  • twisted:非常早的异步网络库,自带HTTP服务器、DNS服务器、邮件服务器等,之后Python官方的asyncio就很大地收到了它的影响
  • tornado:既是异步网络编程库,也是一个成熟的HTTP服务器以及Web框架
  • aiohttp:基于asyncio的网络编程库,可以高效地实现HTTP服务器和Websocket服务器
  • cyclone:作者想要综合twistedtornado两个库,做到implements the Tornado API as a Twisted protocol
MySQL 单机单表切分实践

MySQL 单机单表切分实践

描述

客户的项目使用MySQL做持久化,MySQL部署在单机服务器上,前期在数据存取上没有问题。后来加了一个爬虫项目,爬取百度地图的数据,数据很快堆到了一亿多条,所有的数据都存储在单个的MySQL数据表中,整体的数据量超过了70GB,查询时的效率极低,几分钟才能出来结果。除此之外,前期分配的磁盘空间不足,整体的数据占用量也到了95%以上。所以一方面需要迁移MySQL的存储位置,另一方面需要解决查询效率的问题。

过程

存储迁移

在解决线上问题的时候,我的宗旨一直是尽量别相信中文社区的解决方案(包括本文),不过在做数据迁移的时候图省事直接找了个CSDN照做了,过程都是泪,最后还是老老实实照着StackOverflow做,迁移MySQL存储位置的方案看这里,简要描述如下:

  1. 假设你的迁移目标目录是/data/mysql
  2. 假设你的MySQL配置文件的目录是/etc/mysql/mysql.conf.d/mysqld.conf
1
2
3
4
5
6
1. $ sudo /etc/init.d/mysql stop # 或 sudo service mysql stop
2. $ sudo cp -R -p /var/lib/mysql /data/mysql
3. 打开/etc/mysql/mysql.conf.d/mysqld.conf, 将datadir指向/data/mysql
4. 打开/etc/apparmor.d/usr.sbin.mysqld,将其中所有的/var/lib/mysql修改为/data/mysql
5. $ sudo /etc/init.d/apparmor reload
6. $ sudo /etc/init.d/mysql restart # 或 sudo service mysql start

按照上述步骤就可以顺利完成存储的迁移,如果期间确实遇到了问题,那么就删除存储目录下的ib_logfile0ib_logfile1这两个文件,重新启动MySQL。

查询优化

优化查询的第一个反应就是加索引,查询依据主要是一个varchar的列,所以最初考虑直接对这一列加索引,设置了索引之后一直等它运行完成,结果一直做了四个多小时仍然没有结束。由于这个尝试早于存储迁移,而且加索引的过程中会产生大量的临时文件,所以直接撑爆了磁盘,搞了很久才救回来。也是由于数据量很大的原因,没有做备份就直接怼了索引,现在想起来也是大胆。这个尝试之后就加了块大磁盘,先做好了存储迁移,然后开始考虑单表切分的问题。

就现在的用户量而言,主要的压力并不在服务器本身,所以仍然考虑单机切分。数据表的字段之间没有特别强的关联,而且有几个字段的内容量很大,可是客户端需要的字段比较多,如果做垂直切分最后还是要Join,因此最后做了表的水平切分。客户端在查询的时候总是会带一个地区参数,而且参数只是城市,可以根据区域做水平切分。如果按照省份做切分,理想状态下会把数据表均匀切分成30多份,按照目前的数据增长速度,估计几个月之后又会上升到现在的量级,所以干脆按照城市进行切分,并且这次直接在新表上加索引。

在准备阶段,给数据表一个统一的前缀,结尾加上城市的Canton Id,用代码批量生成Model类,然后Migrate即可(项目基于Django)。接下来就是切分过程,大致思路是按照id每次从旧表中捞出10000条数据,根据city字段判断应该插入的新表,放在临时列表中,然后批量插入整个临时列表。在做切分的过程中还是遇到了一点小坑,首先是Django的查询集缓存问题,规范可以参考官方文档,做的时候有这个意识,但是还是没有足够细心,导致一开始速度慢了很多。另外还有一个更慢的地方,是在拼装新的Model实例的时候,这个过程理论上应该一瞬间完成,可是却成了时间瓶颈,检查了很久发现是一句item.city.canton_id导致了每次都重新查询一次数据库,做了City表中id到canton_id的映射之后这个问题才得以解决。外键写起来是个好东西,可是用起来稍不注意就忘了其凶残的本质,以后尽量不设置外键而是自己维护关联关系,这样才能时刻记住自己在做什么

结果

截至目前,迁移工作仍然在进行中,做完之后再来补…