Mike's Blog

没想到，半年的学习已经结束了。和导师谈妥之后，研二就可以开始实习了，然后就开始了自己的实习招聘生涯。其实，因为目标比较明确，大部分的公司也并不是特别想去。所以就盯上了一家叫做巨硬的外企。然后就开始准备了。 但是主要好玩的地方不是面试的准备，而是拿 offer 的一段插曲。（巨硬的面试挺好过的，只要所有的算法题，都能很快的想到解决办法（不是最优解都可以），然后能够 bug free 的完成编写部分，都能有个很好的结果。） 当时，4.23 面试结束，在 4.27 收到 congratulations 邮件，被告知 offer 已经确认。然后就是精彩的部分了。邮件中说，具体的 offer 信息会在 few days(原话) 发送。所以，就是接下来的一周时间。但是，直到周三，我都没有收到 offer。因为感觉自己的面试过程非常的顺利。所以很是奇怪。发邮件询问 HR ，被告知，offer 还在发，说周四和周五一定会有。于是又开始了等待。最后周五中午还是没有 offer。于是很是紧张，发邮件给 HR，结果她不在办公室，请假了一天。当时就慌了。然后打电话给另一个北京的 HR，让她查一下我当前的状态，结果被告知，offer 在 5.6 号下午两点已经发送，是最早的几批。但是，我没有收到。于是，一番操作下，终于发出来了。。。真的是一波三折。想想如果自己没有找到另一个北京的 HR 的联系方式，或者我的 HR 没有请假（她回了句继续等待），可能就变成了我默拒了。还好最后的结果不错。 以上就是一个小插曲。就这几个月而言，其实投的公司挺多的，但是大部分都是去刷了个满分的笔试，然后鸽了面试。主要是，不是很喜欢某些公司的背书式面试，或者临时抓一个面试官过来面试毫无准备的面试，这让我觉得没有得到应有的尊重。其实，作为一名工程师，最主要的是解决问题的能力，比如面对某一个场景，会设计出来一个怎样的解决方案，同时，在实现这个方案的过程中，你会如何表现，是 bug free 的一次 AC，还是打回重来，而不是 Spring 的事务有多少种写法，或者数据库的第三范式的内容。所以整个求职中都偏向于考察算法的外企(其实也就是巨硬一家)。近段时间，国内互联网的负面新闻太多了。让我产生了一种，究竟实在 make the world better, 还是 make the world worse。所以选择了一个更加偏向于基础技术的公司。 记得巨硬面试的时候，有个流程是参观办公室，当时有个 50 岁左右的美国老太太，听说我们是来面试实习生的，很热情的张开双臂欢迎，这样的一个氛围确实给我留下了很深的印象。而且他的宣讲也特别的别出新裁，其他的公司都在极度的渲染自己的发展有多么迅速，或者未来有多么光明，而巨硬是指很平淡的描述，在巨硬工作会是一个怎样的场景，如何更好的 work life balance。我觉得这就是企业文化上的一个差异。而引申出来的可能就是两个截然不同的工作氛围。至少，我是喜欢后者的。至于技术上的提升，我觉得更多的是周围同事的水平，或者说公司的眼界。 希望之后一切顺利。

这段时间主要是扑在算法上了，这些工程领域的知识有点遗忘了。所以趁着这次复习，复习下之前做过得项目。同时，正好当时，Redis 官方还没有集群方案，所以才有了之前的 Cache 集群方案，现在正好也看看 Redis 官方的方案。 Codis 方案 一张 Codis 官方给出的架构图： 可以看到，它是采用了 proxy 的方式，和 Redis 官方给出的去中心化的思路不同，Proxy 是一种中心话的思路，将 Redis 仅仅作为存储引擎来使用。这一点其实比较符合组件化的原则，每一个组件只需要做一件事。同时，proxy 的方案，也非常利于简化代码的逻辑。 Zookeeper 用来维护整个集群的 metadata 信息。相比较于去中心化的思路，中心话带来的就是一致性问题。比较简单的，在多个 proxy 中，如何维护同一个正确的 redis 集群信息。所以这个使用了 Zookeeper 来进行维护。也算是做到了 HA。 至于 proxy 中的分区算法，依旧是采用的一致性 Hash 算法。这个也算是在这种扩展性上的一个比较通用的处理手段。 记得我们当时讨论过，是否直接采用这个方案进行部署。但是，当时的负责人始终坚持自研，但是最后的方案也还是参考的 Codis 进行，不得不说是一个很没有意思的事情。 一致性 Hash 其实就是将一个一维线性的地址空间做成环状，收尾相接。 同时部署在上面的机器，都会握有一个 index，比如 1024 中的 256，512，768，1024 这四台机器。 当一个 key = 268 值传入时，就会找第一个接近的值，这里就是 512 号机器。 如果 key = 1025 那么，就会 key = key % 1024 从而映射到 256 上。 Zookeeper 如何进行一致性保证 为什么需要 Zookeeper，上文也说过了，就是保证 Proxy 能获取到最新且一致的集群信息。也就是一致性保证。 一致性保障，其实比较完善的解决方案也就是 Raft 和 Paxos 两个算法。这边 Zookeeper 则是使用的叫 Fastleader 的选举算法，在多实例的情况下，通过选举出来一个 master 进行决策，从而避免了多机同时处理导致的不一致。 Fastleader 算法： 先上一个算法流程图： 第一反应就是和，Raft 算法好像啊。 以上是 Raft 协议的一个状态转移图，可以看到，和 Zookeeper 的选举不同的是，他没有固定的 Observing 状态（一直默默参与数据同步，但是不参与投票）。而且，ZooKeeper 中，一旦 server 进入 leader 选举状态则该 follower 会关闭与 leader 之间的连接，从而旧 leader 无法发送复制数据的请求到新的 leader 上，从而避免了干扰。 具体可以看 图解zookeeper FastLeader选举算法。 至此，基本上说了第一个方案。 Twemproxy 方案 这个也是最早的一个集群管理方案了，更倾向于一个基本的 client 端的静态 sharding。而且他的介绍也很简单，就是提供一个轻量级的代理服务，主要是为了减少后端的连接数。。。所以不是很明白为什么很多人都会写博客说用它做集群会很麻烦。。他本来就不是为了复杂集群管理业务而设计的。。 Redis 官方方案 也是一个使用了一致性 Hash 算法的方案。不过他有意思的一点就是去中心化。主要的好处就是，加入 {A, B, C} 三台机器作为一个集群，那么，你连上任一一台机器，你的所有请求都会在 Redis 内部进行处理，而不会暴露在外面。不过坏处也是显而易见的。访问缓存，基本上都是大量的短连接。所以，这边做并不会减少这个问题的产生（Twemproxy）就是因为这个而产生的。 具体的算法实现： A, B, C 三个节点，采用哈希槽 (hash slot) 的方式来分配 16384 个 slot ，三个节点分别承担的 slot 区间是： 节点 A 覆盖 0－5460; 节点 B 覆盖 5461－10922; 节点 C 覆盖 10923－16383. 获取数据： 如果存入一个值，按照redis cluster哈希槽的算法： CRC16(‘key’) % 16384 = 6782。 那么就会把这个key 的存储分配到 B 上了。同样，当我连接 (A, B, C) 任何一个节点想获取 ‘key’ 这个key时，也会这样的算法，然后内部跳转到B节点上获取数据 新增一个主节点 D，Redis 会从各个机器的前段，拿出一部分给 D： 节点 A 覆盖 1365 – 5460 节点 B 覆盖 6827 – 10922 节点 C 覆盖 12288 – 16383 节点 D 覆盖…

作为一个 Emlog 4 年多的用户同时也是众多参与 Emlog 开发者中的一员，做出这个决定确实很难。不过 Emlog 的长期荒废，加上论坛里高质量的内容越来越少。这个也是势在必行。 最后一根稻草是：混乱的社区。于是乎，最后转向了 WordPress。 说道迁移，最麻烦的时数据的备份，之前也想过迁移，但是总是在最后一步卡住了，因为缺少一个合适的工具进行数据的导入导出。自己写的话，比较麻烦，因为对应的数据库表众多（其实就是懒）。 于是乎，这次我觉定自己玩一下。先是查到了这么一篇文章：emlog 5.3.1程序转入wordpress程序教程。得到了这么一个优秀的脚本 em2wp.php。 但是跑了一下，发现问题挺大的。因为这个版本的 php 是用 5 来写的，现在所有的云主机，基本都是 7 打底，所以就会有兼容性问题: WordPress 版本更新之后，对应的表结构发生了改变。 PHP7 以后不再支持 mysql_xxxx 函数。 代码并不会显示错误代码。 中文字符集的乱码问题。 于是自己修改了下，并且运行成功。代码 GIST – em2wp.php。 代码不会修改 emlog 原始表结构，所以放心的在线上执行，毕竟如果是迁移，Wordpress 的库内容是无足轻重的。并且，我相信各位都是可以成功看到 GIST 的。 不过总体而言，迁移非常的成功。剩下的 https，资源文件，域名，postId 保持一致，则都是体力活了。 本来以为一切都已经搞定了，可是，我去 google 搜了一下我的博客，发现他的 url 为 https://mikecoder.cn/post/{postId}，然后看看其他人引用我博客的时候的 url 则是 https://mikecoder.cn/?post={postId}。 不管是哪一种，WP 都没有默认的支持，前者比较好办，直接在后台进行修改就好，修改默认的链接为 /post/%postId%/ 即可，后者则是比较麻烦。因为不太想修改 WordPress 的源码（不太清楚有多少地方需要修改）。想了一会，最后确定添加 NGINX 重写规则的方案（还好会一点 NGINX）。 添加注释中的代码即可。将 ?post=(\d+) 的请求全都重定向到 WP 识别的请求上。 server { listen 443; server_name www.mikecoder.cn mikecoder.cn; … index index.html index.htm index.php; location / { #===================================================== if ($args ~* post=(\d+)) { set $args ”; set $id $1; rewrite ^ https://mikecoder.cn/post/$id; } #===================================================== try_files $uri $uri/ /index.php?$query_string; index index.php; } location ~ \.php$ { fastcgi_split_path_info ^(.+\.php)(/.+)$; fastcgi_pass unix:/run/php/php7.0-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } } 至此，基本上所有的配置已经完成。现在的主要任务又变成了，如何快速的了解 WordPress 的代码结构。同时争取成为 WordPress 的开发者。 最后感慨下，Wordpress 确实是做的最完善的一个博客系统。 为什么不用 hexo 作为一个稍微会一点 php 的人，还是想自己能魔改整个系统的。 作为一个 hexo 的插件开发者，我也知道 hexo 用来写博客的局限性。不是很愿意被限制。 我正好买了 3 年的云主机，不用也是浪费啊。 大量的数据不太好使用静态博客迁移。 为什么不用 typecho 其实和 emlog 一样的问题。WP 能满足所有的功能，且大部分做的更加完善。所以没理由使用 EM 和 TY（追求简单除外）。 论坛活跃度不如 WP，想获得新的主题或者插件，都比较困难。 EM 和 TY 的活跃用户仅限于国内。接轨世界的话，WP 确实是最好的选择。 最后的最后，感谢 EMLOG 的开发者。