突然发现有好几个月没写博客了。做这个博客的初衷是记录我的技术成长之路，当然也是为了找工作面试的时候能作为加分项。听过来人说，电脑一旦从爱好变成了饭碗，就没有那么好玩了！的确，工作之后对技术的热情没有之前那么强烈了。有时就想我真的一辈子要以编程为生吗？只做技术可能一辈子都帮别人打工。可是现在摆在我面前的路好像只有技术这一条路，既然当初选择了这条路，就应该义无反顾的走下去。额，好像有点跑题了，就当我是在扯淡吧。

了解了关于分布式相关的一些东西

之前陆陆续续了解过一些分布式的东西，分布式领域著名的三篇论文 BigTable, GFS, MapReduce 都略读了一下，但是并没有很深入的研究。mit6.824的lab已经完成了lab1部分，lab2部分的PartA 也已经完成了，现在卡在了raft的日志复制上。其实raft本身好理解，但是naive实现很难通过所有case, 运行测试用例的时候总是有时能pass有时又fail, 而且还要考虑各种data race，另外分布式debug时打印出来的日志很难去辨别哪个是先发生，哪个是后发生的，时间线很乱。最近很忙，没有时间去完成这个lab, 当是之前挖的坑之后慢慢补吧。

web 相关的东西

最近的工作是 web 后台开发，主要是用Flask框架实现一些后台功能，处理历史遗留的 bug，同时用Go写一些api接口。大部分都是写业务逻辑，其实感觉挺没意思的。最近出现了一个 bug 要在生产环境打印日志，发现用Python的logging模块打印日志时在DEBUG环境下可以显示时间，文件行数，但在生产环境下并不会显示，查了Flask的官方文档是说，在生产环境下Flask的日志会隐藏很多细节，而且对于大部分小型应用没有人会去看日志，你需要的应是异常发生时的邮件，然后你会得到一个警报。这个解释让我感觉很不爽，同时也感觉到自己对这个框架的了解还不够，之后可能要恶补一下Flask本身的实现，包括Werkzeug工具库，以及WSGI标准。

Elasticsearch

Elasticsearch是我唯一接触的与大数据相关的东西，刚来公司的便让我处理关于Elasticsearch优化的问题。我们主要是用es来处理线上服务日志，我看了一下每天大概有30G的量，这个量对业界来说应该是很少的了，业界动辄上 TB 级别，甚至是 PB 级别。es是部署在一个 4 核 8G 的云服务器上，单机单节点（感觉完全没发挥 es 分布式特性），因为单条日志的查询的方式是以通配模式匹配搜索的，所以有些日志返回很慢，之后考虑按field查询。日志收集是内部用Go写的一个简单的UDP服务，服务日志以报文的形式扔给UDP服务器，然后UDP服务向es写入日志，开始业务老是反应有丢日志的情况，我在线上排查了一下，发现es写入队列的大小 2000, 遇到高峰期的时候，因为队列满了，es会拒绝写入请求。解决的方式是限制写入的速度，用Go的channel实现这个功能非常简单。

后来了解过一些ELK相关的东西，用Kibana做过数据可视化分析，发现非常方便，只要点一点就有各种图表。通过ELK栈还了解了Kafka消息队列，ZooKeeper分布式服务框架以及Scala语言（断断续续学了一点），同时发现Java或是运行在jvm上的语言在大数据领域有着不可撼动的地位，一系列的开源组件Hadoop, Spark, Storm, Flume……都是由其构建的。

不过我现在主要用的是GO和Python不知道以后有没机会接触这些大数据相关的东西。

数据库相关

我们现在主要用的是PostgreSQL, PG应该是当今最好的开源数据库了，一系列新的特性，支持json, array, GIS, 非常方便。不过遇到的问题是传统的关系型数据库，一旦数据量过大，达到了上亿的级别，不管是查询还是插入都会变得很慢。传统的方法无非就是分库分表，PG是支持分区表的，不过要写触发器，操作不当可能会引起锁表。有想过用PingCap的TiDB, 但是好像换数据库会遇到数据迁移这种棘手的事情，想想还是算了，老老实实分库分表吧。

编程语言，算法

现在最熟的还是Python，写起来是又快又爽。不过Go也慢慢变成主力语言，现在觉得Go还是更适合做底层，做一下网络相关，分布式相关的库会比较好，并不觉得Go适合做 web 开发框架，而且写业务逻辑用Go的话，开发效率远没有Python, PHP等动态语言来的快，不是那种特别注重性能的模块的话，不推荐上来就用Go。

算法方面现在 leetcode 已经刷了快一百题了，不过刷题都是心血来潮就刷几题，并不规律，虽然现在的工作好像用不上算法，但是算法基础应该是每个程序员必备的，还是应该继续坚持刷下去。

TODO

  • S 完成 6.824 的 lab
  • Flask 框架的详细深入了解