天道勤酬，恭喜Wings获得TI6冠军！

1
2
3
4
5
6
7
8

一支曾因没有LOL分部而被DACE拒之门外的战队，
一支队服上连赞助商Logo都没有的战队，
一支全队没有一个人开直播的战队，
一支为了梦想坚持到底的战队，
一支创造了奇迹的战队，
一支无敌的战队！
Wings！
来自微信公众号 天辉夜魇    

入场

昨晚看小说三点多才睡，但是早上七点钟依旧爬了起来。展会是九点整入场，提前出发是希望入场的时候不要排那么长的队伍，结果到了才发现已经有很多人在排队……

排队的时候和小伙伴们聊天，慢慢的把人凑齐。我其实主要就是想看水濑祈，毕竟就是因为她会来才决定出门看这个展会的，腹黑的上神大人还是很萌的。Harmony Ribbon 绝赞发售中！

门票有两种，很早买的是邮寄的纸质票。近期买的是电子票。电子票得多排一个队兑换纸质票。

EXPO

进入之后领了本小册子，仔细看了下，其实有三个馆（EXPO，MAX和电竞），主要参观的应该是EXPO。

川原今天有签售，貌似买满200可以抽奖，中了去要签名。要排队这么麻烦的事情我是不会去的，主要还是看看手办。

万代的高达馆，一些模型挺好玩

FATE的痛车

11：30有心欲呐喊主创见面会，水濑祈来了。不让牌照，我很老实的遵守了。正面太多人，我们站在侧面，感觉距离反而进了。真人好可爱，(๑•ᴗ•๑)。

穹妹这个数量限定的手办，一开始没排队，后面想买的时候已经没了。(┬＿┬)

买了两本画册，走之前5个小伙伴买了小圆的5个人，凑成了五色战队。我的小圆明明很可爱，盒子也最大，为什么价格最便宜，不解。

MAX

这个貌似是同人馆，但是没啥好东西买。主要就是等水濑祈一点半的歌，听完就走。此时腿已经很疼了，果然家里最舒服。

这个馆COS挺多的，有个COS成Nico的在拍雷姆，感觉很好玩。话说这个Nico脸有点像空丸啊。

电竞馆

G联赛Dota2的决赛，同福打IG，没其他好玩的东西，拍了张图就走了。今年Ti6中国队加油！

归途

临走拍了一张，发现这个位置过一条街就是上次看Dota2春季特锦标赛的梅赛德斯-奔驰文化中心。

小圆

小圆的浴衣做的很精致啊，为什么这么便宜。(/ □ \)

什么是统一社会信用代码

很久很久以前，注册一家公司会有公司营业执照，上面会有营业执照注册号。公司赚钱了，要依法纳税，去税务局又会办理一个税务登记证，上面又有一个编号。
一个人只需要一个公民身份证号码就可以确定了，公司在不同的场合却需要多个证件编号。对企业而言，麻烦，办各种手续都不方便。对管理者而言，监管不便，管理成本高。

我们都知道，统一的标准可以减少成本，提高效率。GOV作为某种意义上的特大企业，也明白这个道理，于是有了三证合一，统一多个编号，使用唯一一个编号。

企业编号决定统一使用一个标准，个人编号已经是一个标准，于是GOV再加了一把劲。怀着为了更好的服务大众，构建信用社会的目标，在现在的基础上，GOV倒腾出了统一社会信用代码制度。

这个企业的身份证号码就是统一社会信用代码，用于替换之前企业各个证件上的编号。和公民身份证号码一样，统一社会信用代码也是18位。

统一社会信用代码的用处

• 以前，业务上标识一家企业通过公司名称或者营业执照注册号，这些都不稳定。名称可以变，注册编号长度不确定。
• 以后的新数据可以统一的通过统一社会信用代码标识，这个在稳定性和权威性上都好于以前。

统一社会信用代码编码规则

工商总局在官网上发布了标准文件：法人和其他组织统一社会信用代码编码规则。和身份证编号类似，根据编码规则可以进行一下判断并获取有用的一些信息。我们在审核的时候，可以通过检测编号来判断公司的真假。

下面是我用PHP实现的简单检测函数，管理部门、机构类别、登记地区这些信息还没有充分利用起来，只根据校验码检测。

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
27
28
29
30
31
32
33
34

// 法人和其他组织统一社会信用代码
// 编码规则：http://qyj.saic.gov.cn/wjfb/201509/t20150929_162430.html
public static function unifiedSocialCreditIdentifier($value) {
    // 统一代码由十八位的阿拉伯数字或者大写英文字母（不使用I、O、Z、S、V）组成
    if (!is_string($value)) return false;
    $value = strtoupper($value);
    if (strlen($value) !== 18 || !preg_match('/^[\dA-HJ-NP-RT-UW-Y]{18}$/', $value)) return false;

    // todo 第1位：登记管理部门代码检查
    // todo 第2位：机构类别代码检查
    // todo 第3位～第8位：登记机关行政区划码检查
    if (!is_numeric(substr($value, 2, 6))) return false; // 简单检查，这部分一定是阿拉伯数字
    // todo 第9位～第17位：主体标识码检查
    // 第18位：检验码检查
    $加权因子 = [
        1 => 1, 2 => 3, 3 => 9, 4 => 27, 5 => 19, 6 => 26, 7 => 16, 8 => 17, 9 => 20,
        10 => 29, 11 => 25, 12 => 13, 13 => 8, 14 => 24, 15 => 10, 16 => 30, 17 => 28
    ];
    $代码字符集 = [
        0 => '0', 1 => '1', 2 => '2', 3 => '3', 4 => '4', 5 => '5', 6 => '6', 7 => '7', 8 => '8', 9 => '9',
        10 => 'A', 11 => 'B', 12 => 'C', 13 => 'D', 14 => 'E', 15 => 'F', 16 => 'G', 17 => 'H', 18 => 'J', 19 => 'K',
        20 => 'L', 21 => 'M', 22 => 'N', 23 => 'P', 24 => 'Q', 25 => 'R', 26 => 'T', 27 => 'U', 28 => 'W', 29 => 'X', 30 => 'Y'
    ];
    $校验值 = 0;
    for ($i = 0; $i < 17; $i++) {
        foreach ($代码字符集 as $k => $v) {
            if ($value[$i] === $v) break;
        }
        $校验值 += $k * $加权因子[$i + 1];
    }
    $校验值 = 31 - ($校验值 % 31);
    $校验值 = ($校验值 === 31) ? 0 : $校验值; // 校验值为 31 的时候，校验码使用 0 表示
    return $代码字符集[$校验值] === $value[17];
}

我的工作系统一直是Ubuntu LTS。21日最新的xenial发布之后，马上安装进行了一些体验。Ubuntu 16.04 LTS的一些主要更新可以看这里。

外观变化

• 整体外观和上一个LTS相比变化不大。
• 挂载硬盘的时候弹出标志会显示成一个突出的按钮，个人感觉没有之前好看。
• 中文字体有变化，感觉更圆润。

必要设置

• 关闭访客账户和之前介绍的差不多，Ubuntu自己在帮助中心也有说明。
• 不需要手动在隐私设置中关闭在线搜索，默认已经关闭。文件记录、
  发送错误报告还是要自己动手关闭。

软件变化

• 推荐使用apt来管理软件，代替之前的apt-get。
• 感觉更新需要连接的源变少了，使用apt update只会出几条日志，比起之前滚屏清爽很多。
• 大量基础软甲包更新，我比较关心的有Kernel 4.4、Python 3.5、OpenSSH 7.2p2、PHP 7.0、MySQL 5.7、GCC 5.3，这些基础软件都升级到了最新的稳定版。看日志我一开始以为和Arch Linux一样只有默认的Python3了，实际使用发现只有服务器版是这样的，桌面版2和3都有，并且更新到了最新版。

  1 2 3 4

  ➜ ~ python Python 2.7.11+ (default, Apr 17 2016, 14:00:29) [GCC 5.3.1 20160413] on linux2 Type "help", "copyright", "credits" or "license" for more information.

  1 2 3 4

  ➜ ~ python3 Python 3.5.1+ (default, Mar 30 2016, 22:46:26) [GCC 5.3.1 20160330] on linux Type "help", "copyright", "credits" or "license" for more information.

• 依旧预装了Amazon等鸡肋应用。这些可以通过一条命令全部卸载 sudo apt remove unity-webapps-common。
• 去掉了Ubuntu软件中心，使用了Gnome软件改成的Ubuntu软件。我使用感觉响应很慢，还是习惯直接敲命令行。
• 支持snap包，最近新闻好像Firefox以后在Ubuntu上就用snap包发行了。这个功能暂时没用上，但感觉挺不错的。

第三方软件

• Chrome 可以正常使用，但是他签名使用的是弱密钥，更新会有提示W: http://dl.google.com/linux/chrome/deb/dists/stable/Release.gpg: Signature by key 4CCA1EAF950CEE4AB83976DCA040830F7FAC5991 uses weak digest algorithm (SHA1)。另外，默认设置中文字体显示特别细，需要自己再设置一下。
• Atom 我从PPA安装的，正常使用，很方便。
• WPS 用的Alpha 20 Patch 2，文件名wps-office_10.1.0.5503-a20p2_amd64.deb，没有问题。
• 搜狗拼音 用的最新的包sogoupinyin_2.0.0.0072_amd64.deb,dpkg -i安装之后还需要apt-get -f install才成功，使用起来没问题。安装包感觉还没做好，以后应该更方便才行。
• 快盘 直接安装，文件可以同步。

其他

• zsh、git、htop、tmux、keepass2、openvpn 等常用软件从源里安装都正常。
• 配置好Java环境之后，PhpStorm和PyCharm正常。
• 我用来干活的系统已经从14.04 LTS切换到16.04 LTS

Kafka简介

• 分布式日志分发系统，可用于消息队列
• 创建背景
  • LinkedIn开发，2011年贡献给Apache基金会
  • 使用 Scala 编写
• 设计目标
  • 以时间复杂度为O(1)的方式提供消息持久化能力，即使对TB级以上数据也能保证常数时间复杂度的访问性能。
  • 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条以上消息的传输。
  • 支持Kafka Server间的消息分区，及分布式消费，同时保证每个Partition内的消息顺序传输。
  • 同时支持离线数据处理和实时数据处理。
  • Scale out：支持在线水平扩展。
• 和常用MQ对比
  • 吞吐快
• 与ZooKeeper配合使用

Kafka架构

Terminology

Broker
Kafka物理机器节点，一个Kafka集群包含多个Kafka Broker

Topic
消息的类别（逻辑上概念）

Partition
消息存储物理上的概念

Producer
消息生产者

Consumer
消息消费者

Consumer Group
每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）

拓扑结构

• Kafka通过Zookeeper管理集群配置，选举leader，以及在Consumer Group发生变化时进行rebalance。
• Producer使用push模式将消息发布到broker，Consumer使用pull模式从broker订阅并消费消息。

Topic & Partition

• Topic在逻辑上可以被认为是一个queue，每条消费都必须指定它的Topic
• 物理上把Topic分成一个或多个Partition，每个Partition在物理上对应一个文件夹，该文件夹下存储这个Partition的所有消息和索引文件。
• 消息文件会分成多个segment，每个segment以该segment第一条消息的offset命名并以“.kafka”为后缀。
• 索引文件标明了每个segment下包含的消息的offset范围，如下图所示。

• 在一个Partition上，每条消息都是顺序写入，因此在一个Partition上是有时序的。

Producer消息路由

通过指定key将消息发送到某个Partition。

Consumer Group

同一Topic的一条消息只能被同一个Consumer Group内的一个Consumer消费，但多个Consumer Group可同时消费这一消息。

HA

Replica 分配策略

尽量将所有的Partition均匀分配到整个集群上。
Replica分配算法如下：

• 将所有Broker（假设共n个Broker）和待分配的Partition排序
• 将第i个Partition分配到第（i mod n）个Broker上
• 将第i个Partition的第j个Replica分配到第（(i + j) mode n）个Broker上

消息接受

1. Producer通过ZooKeeper找到Partition的Leader，只将消息发给Leader
2. Follower从Leader pull数据，在接收到数据后就立马向Leader发送ACK。（一个在性能和持久化上比较好的平衡）
3. 一旦Leader收到了ISR中的所有Replica的ACK，就认为已经commit，Leader将增加HW并且向Producer发送ACK。

对于已经commit的消息，Kafka只能保证它被存于多个Replica的内存中，而不能保证它们被持久化到磁盘中，也就不能完全保证异常发生后该条消息一定能被Consumer消费。但这种场景非常少见

Leader会跟踪与其保持同步的Replica列表，该列表称为ISR（即in-sync Replica）。如果一个Follower宕机，或者落后太多，Leader将把它从ISR中移除。

Leader Election

ISR谁先连接到就是谁

MongoDB提供了TTL索引自动从集合中删除过期文档，这个功能在存储日志等一些只需要在固定时间内存储数据的场景下使用起来非常方便。最近用了一下，发现这个功能没有想象中的那么好。

TTL索引的建立很简单，要求是只能在一个field上创建，并且这个field是一个Date类型数据或者是一个包含Date类型数据的Array。
在创建索引的时候只需要多增加一个expireAfterSeconds参数，在field加上这个expireAfterSeconds的时间大于当前时间后，这个文档就会被自动删除。

TTL索引相比一般索引还多了一些合理的限制，比如：

• 必须是单个字段（field），多字段不支持
• _id字段不支持TTL索引
• 定长集合(Capped Collections)不支持
• 不能使用createIndex()来改变已有索引的expireAfterSeconds值。可以使用collMod尝试，失败则只能删除并重建索引
• 当目标字段（field）已有非TTL索引，必须先删除旧的，再重建新的TTL索引。不能建立一个只有这个参数（带有expireAfterSeconds）不同的索引

TTL索引有一般索引的功能，上面的限制大多数情况下能让人接受。但是因为TTL索引的删除机制，想要好好的用它，还需要斟酌。

首先说一下TTL索引的实现方式：
mongod每60s会启动一个后台线程来删除过期文档，这就意味这MongoDB的TTL不同于Redis，是一定有延迟的。
而且这个60s也不是硬性保证的，万一节点压力非常大，过期文档的删除时间会超过60s。
MongoDB只保证文档最后一定会删除，在没有删除之前，即使过了失效时间，文档依旧可以查询。

在副本集的情况下，TTL后台线程只会在主节点删除文档，然后通过主节点把删除操作同步到从节点。但是每个从节点自身也会执行自己的TTL后台线程。
当主节点压力很大，从节点压力小的时候，就会出现过期文档在主节点依旧可以查询，在从节点却已被TTL索引删除的情况。

索引的建立方式也会对这个造成影响。为了避免对读写造成堵塞，我一般会使用background后台建立索引。
当使用background方式建立索引，TTL线程可以在建立索引的过程中删除过期文档。而foreground则要等到索引建立完成才可以开始删除。

TTL Indexes和Capped Collections实现的功能其实有点类似，一个是是限定时间，一个是限定大小，但是TTL Indexes的不确定性大了很多。要使用他们肯定要根据具体的场景，我更倾向于使用确定的Capped Collections。

Reference:

• TTL Indexes
• Expire Data from Collections by Setting TTL

今天Github出现故障，离线维护，认识了几个可爱的图标。

一个是独角兽，不知道是不是彩虹小马神教里面的。

过一阵子变水管工了。

这个是查看Github运行状态的地址：https://status.github.com/

这是该系列的第六本，但是内容读起来却像一本全新的书（贬义）。全文大部分都是师姐和师兄那无聊的吐槽，中间再穿插这一些动漫梗，大概是江南想以此引起动漫读者的共鸣，但实际上这种流水账凑字数的内容，很乏味，难以让人有更多的想象。龙族I铺垫剧情，介绍世界观，结尾三峡战斗感觉很好。龙族Ⅱ靠着夏弥的死和面瘫师兄的爱情也还不错。龙族Ⅲ厚厚的三本，虽说拖沓，但是小怪物绘梨衣的悲剧结局赚了一票眼泪。到系列第六本，应该更加成熟了才对，但是完全不是这样。

这里用豆瓣的一份评论很贴切

整本书你就只能看到江南像一个祥林嫂一样大段大段的描绘人物感情，不断给你煽情，拼命想戳中你的泪点，就好像瞎子射箭一样，抓了一堆的箭来，胡乱射出去，总有一只会中的。

而我呢，书里那大段大段煽情的戏码就像一只小爪子在给我挠痒痒，偶尔挠中一次，我会心头一动，之后他继续挠，我还会起鸡皮疙瘩，再往后，我只会想说你丫烦不烦，我真的快要吐了。

我一直都觉得，作为一个作者，保持感情的克制是很有必要的，虽然江南一直都不是一个克制的人，但这次，他完全就是打开了煽情水坝的大闸，恨不得把读者淹死。

好好好，我知道路明非是个衰仔，诺诺在他最衰的时候把他拉了出来，于是她就是他的电，他的光，是他唯一的神话，但能不能别老叨逼叨逼这些段落，说一两次也就算了，每次都说是几个意思，能不能好好写剧情。

还有那个唐僧和猴子的故事，江南你怎么了？一个小破故事居然在整本书的后半部分不断被拿出来讲，几个人物讲来讲去把它奉为圣经一般，搞得我一看到什么唐僧小猴子就忍不住跳过去，我都能感觉到那些情节煽情过度拧出来的苦水。

另外苏晓樯和那个黑太子集团大公子在书里占据大量戏份是几个意思？强行扯上一些廉价又矫情的情节，不断重复他们那些煽情又幼稚的故事，很多桥段简直看得我尴尬症都要犯了好吗。

龙族IV依然会大卖，但是看的人真的不会再有期待了。我看这本书的时候，满脑子冒出来的不是剧情的猜想，而是满满的回忆。我会看龙族，就是因为回忆，因为龙I出现的两句秘籍show me the money和black sheep wall。因为小学玩了两年的SC，眼睛才近视，所以SC作为目前唯一一款在我身上留下了痕迹的游戏，印象绝对的深刻。看见一个玩星际的主角，很自然的就看了龙族。

时间是一个轮回，当时看龙族想的更多的是六年前，而现在看龙族，想的也是六年前。2010年，高中。每周稳定的看《知音漫客》和《龙漫少年星期天》；和同学讨论的火影还是佩恩六道在火影村这个最高潮的剧情；看完了整套《明朝那些事儿》，成王阳明这个妖孽人物的粉丝；从这年开始追轻小说传勇传（这本2002年开始连载的小说也是个坑）、夏娜和零使；推完了缘之空，现在还记得刚玩的时候只想妹线，谁都没选，最后进女仆线被醉酒女仆推倒的窘境；元旦是班上半数的男生去网吧通宵Dota，能够十人对黑。那种氛(fēn)围真的好玩~～～

扯远了，再说回这本书。龙族在商业上是成功的，江南就是靠着这个拿了几年的作家富豪榜第一。但是剧情上已经有坑的趋势，看过的人会怀着微小的期望继续追下去，没看过的人可以畅快忽略之。

Javascript的入门书籍，一句话评价是：
看之前我知道Java和JavaScript是不同的，看完之后我知道JavaScript和jQuery是不同的。

很不错的Redis入门书。之前在Kindle上看了盗版的第1版，现在买的第2版，新版主要增加了Redis3.0相关的内容。

速成类书籍，前面都是对本书将要介绍的对象进行简单的介绍。从这本书我知道了Redis是REmote DIctionary Server的缩写，这也是我看完第一版之后唯一记下来的东西。（这点在官网的F&Q有写，但很多人估计不知道。）

介绍完Redis是什么，50页，1/4的内容过去了。再介绍一下常用的命令，到100页。然后介绍一下在 PHP、Python、Ruby和Node.js上用库连接Redis，我们来到了130页。这部分用过Redis的基本可以跳过，要用了再去官网看。
这些内容中我觉得只有事务有意思，可以归结为Redis 在事务失败时不进行回滚，而是继续执行余下的命令，使用的时候要注意。

130页之后，水分值降低。剩下四章，主要介绍了我感兴趣的三个点：

• 脚本
  • 因为Redis是单例，脚本会作为整体执行，所以是原子操作
  • Redis内部可以使用Lua脚本。（自己搜了解到:一个完整的Lua解释器不过200k，在目前所有脚本引擎中，Lua的速度是最快的。这一切都决定了Lua是作为嵌入式脚本的最佳选择。）
  • 通过几次强调Lua的数组是从1开始，成功的让我从和谐的玄学角度上不喜欢Lua
• 持久化
  • RDB 和 AOF
  • flushall这条命令可能会触发save
• 集群
  • Redis3.0添加的可用的集群功能
  • 哨兵2.0
  • 集群的配置、搭建和要注意的点，插槽这个概念。
  • 以上两个很遗憾都没有任何配图，需要耐心阅读，有配图会好理解很多。但是文字解释很详细，一步一步说明哨兵、集群的行为。能让人理解各个节点之间怎么监控，怎么选举。

剩下的内容就是一些管理相关的了，包括

• 安全

Redis只适合Redis适合的场景。Redis Crackit这类应该需要注意。

• 通讯协议

介绍了Redis客户端之间使用的通讯协议，利用telnet连接一个客户端然后模拟通讯，这个挺好玩的。