坚持了快一年的健身大业，被荒废无遗
前段时间和老爹视频，被说好像已经没什么棱角了呃，凌乱风中
不同心情，甚至休息状态下，喜欢听的歌的类型似乎都是不同的，在我困的不行的时候，听如此温柔的歌，早就切了好吧
Jasmine Thompson《Let her go》，很毒，深情
Future of Forestry《You》，很空灵，适合在悠闲的环境下听，幸福感满满
房东的猫《秋酿》
谢春花《一棵会开花的树》
上周面试情况
网易乐得电商
差点把pad落在那了，走了快一公里才意识到，累死我了
股票价格发布订阅
TCP长链接，实时接收股票价格信息。
用户订阅股票的价格，如设置白银价格涨到35时提醒，低于20时提醒等。给出一个解决方案。
- 第一个思路，简单粗暴设计了一张数据库表，记录用户的订阅信息，当接收到股票价格的时候，查表，给相应的用户发送消息。
- 第二个思路，看样子，似乎是一个范围查询的问题，回想到Redis里面有一个有序集合的数据结构，可以通过logN的复杂度找到范围内的元素，所以可以用跳表存储用户订阅股票的价格，这样子每次收到股票价格的时候，可以快速的找到订阅了小于这个价格的用户，也能快速的找到订阅了大于这个价格的用户。
- 第三个思路，面试官给的，他说不知道你怎么注意到范围的问题的（我一脸懵逼），一般首先考虑的是key-value的存储，订阅的价格为key，相应的用户为value，当时觉得好机智啊。回想起来，发现不如跳表，因为key-value，避免不了遍历key的过程。因为有多个订阅价格，所以每次接收到股票价格的时候，是需要去遍历key的。
多个维度数据的聚合查询
类似于数据库表的结构，说我之前其实已经接触过类似的工具。
当时一时半会儿不知道指的什么，瞎说了一个离线计算，就是把聚合的列，预先算好，存储起来。后来面试官说，ES或者是Solr，是不是可以实现相应的功能。ES或者是Solr更倾向于模糊查询，在实习的时候使用过，在百万级的文档查询上面查询效率确实很高，但是经过分库分表优化过的SQL语句，其实也能做到这个程度，只不过ES和Solr也做了很多索引之类的工作。还需要在原理方面多加学习呀。
后续 面到HR面了 不过面完之后有些许失落，莫名的失落，可能适逢天降阵雨吧
百度凤巢算法
原来投的开发的，不知道怎么成算法了。而且去的那天天气不好下雨，后厂村路呀。约的十点，结果面试官迟到了一小时，十一点才到的。面试官超级和蔼，看到的第一眼就原谅他了，2333，就是这么看脸
因为是算法岗，机器学习什么的，我当然不会啦。用面试官电脑敲了一个找到最大联通区域，后来就给我转部门了。其实是想试试算法岗的面试的，真是面不来哎，一面面试官犹豫了好久，要不要让后面的面试官来面一下，发现真的木有什么好面的唉
挺好的，看起来似乎只能开发一路黑到底了，看看Kafka源码，好吹逼什么的
起个文章的标题真的很难，如果不能带走一切，希望可以带上我的电脑，耳机，pad和kindle，┗|｀O′|┛ 嗷~~，还有键盘
