工作半年总结

过两天，就是在公司工作半年的日子，写下点什么东西，算是总结吧。

在公司主要做了以下几个东东/模块。

1 MiniStore，公司内部是这么叫的，michael给取得名字，就是另外一篇日志里面提到的基于内存的key-value存储系统。当然，在实际应用中是存在改进的。首先是封装了java的接口，结上层程序调用。另外就是支持删除的操作。在支持delete操作版本的情况下，key value长度分别为8个字节，80%利用率的情况下，用4G内存可以存储1.6亿条记录，支持快速查找，hash级别的。之所以选80%利用率是为了达到性能与利用率的平衡。

目前的使用情况，1）商品库的排重逻辑。2）商品库的导出逻辑。3）jason开发的skvs(simple key value system)

2 公司的商品库

目前主要集中在索引商品库上，线上的商品库暂时没有时间顾及，索引商品库是michael开发的，现在基本由我来维护，负责新功能的开发，以及老bug的维护。线上商品库目前由我和miachel同时维护，过段时间可能才能全部接过来

商品库是我们这个垂直搜索引擎的一个核心子系统，是我们下载系统中负责存储的部分，目前存着1亿的商品数据。所有的数据有两份，一份在索引商品库中，另外一份会同步到线上商品库。索引商品库是我们内部使用，编辑/运维人员用来做修改，统计使用。同时每天会起一个任务，导出8000万的商品导出来给引擎那边建索引。

3 Url跟综工具

Url跟踪工具是用来跟踪一个Url从发现开始到进入到我们商品库中，在我们系统里面所走过的关键节点，方便运营/产品人员用来追踪一个产品url，同时也极大的解放了开发人员的时间。以前在查一个url为什么没有入库，或者是出了问题的时候，需要链接库、爬虫、商品库三方面同时去定位，现在在追踪系统上，一目了然。

在做这个系统之间，大概做了一下调研，发现现在做搜索的，无论是大搜索还是垂直搜索的，都没有做这个东东。对于做大搜索的，这个的存储是一个庞大的数据量。对于垂直搜索的，窃以为暂时可能还没这个实力，或者没有顾及到这一部分。所以这个东西目前来看而是业界领先的。

目前系统已经部署在一台租用的机器上（米钱），4核,16G内存，4块硬盘，目前用掉了12G内存，可以存储1.6亿的url的消息记录，每个url最多存100条消息（当前系统上还部有另外一个东东，迁出去，如果把DS也迁出去，可以扩容到2.4亿）。结合我们自身的情况，目前之存了b2c的链接，因为是这我们最为感兴趣的商品。

现在每天接受3千万条消息左右，峰值5千万，没有达到系统的极根。系统存在的瓶颈估计会在每条url都存满了url的记录之后，每条消息大概100个字节，那是单条url就是10k(100*100)。因为系统每写一条记录都要将这10k的记录读出，然后替换到里面的部分，在写入，读出是一个随机的过程，所以将来系统每秒估计能处理100条url，系统性能会显著下降。目前针对这个问题已经做了第一版本的优化，进一步的优化还在考虑中。

4 pageDB

pageDB，顾名思义，就是用来存page的地方，这个有点像大搜索的存储，只不过我们远远到不了那个量级，这个要求也是只存b2c的链接对应的url，现在b2c的商品数也就1kw的水平。所以存储起来就是小意思。所以用hadoop+ hdfs就有点浪费，虽然我有这个想法，呵呵。

pageDB最开始由michael开发的，做到一半的时候，他有更紧急的任务，就交给我了。其实pageDB跟tracer的架构是完全一样的，只不过pageDB规模小些，也就在千万级别这个水平，刚接过来的时候，刚做完miniStore不久，对java也是多年不碰，所以还是花了很多时间来研究的。换到现在的话，估计就跟切菜一样。

不过pageDB还有一个重要的需求没做完，就是抽取的过程，因为沈阳分公司一直delay，所以详细的需求一直没整出来，下周可能要开始做这个东东吧。

5 广告系统的导出

广告系统最开始的存储考虑的相当复杂，不过后来砍掉了，那是因为现在广告系统中没有那么多的商家过来投广告，所以基于mysql的库完全可以撑得住;另一方面，广告系统中有着复杂的关系需要维护，所以用key-value来存感觉效率不高。后来只是在mysql上做了一个导出的工作，几句sql语句，搞定

以后这块肯定会在做优化，不过到了做这个优化的一天，投入应该是值得的。有这么多公司来投广告，怎么做都值得啊！

6 Finite State Machine Libary

这个东西其实早就做好了，一年前都说要发布出来的。但是一直delay。到了这个公司以后，一直忙于公司的事，没有时间。前两天10.1，没找到啥乐子，于是在家整理了一下，发布了出来。

Fsm lib算是我在alcatel-lucent一年半工作的总结，技术上的总结。它是一个基于状态机的多线程的库，特别适合用于涉及到状态转移的场景中，详情以在前面的blog做了介绍，就不过多废话。当前本还还打算做完这个以后结合Ace做一个高性能的server来验证一个这个库的，后来因为懒+离职，暂且做罢。

以后可能会不定期的更新，不过肯定不会太频繁。主要是用来保持对自己看家语言的敏感度吧，嘿嘿。

做了总结，才发现自己已然做了很多东西，来了半年多，跟同学说的最多的话就是，我很忙，后来不好意思说忙（毕竟我哪有影@帝忙了），只好改口说最近事情很多。这么一算下来，确实也算是有些东西吧，至少这6个月，日子没有白过。毕竟我在ALU一年半，除了第一个系统外，其它别的都是在已有系统上做一些修修补补吧。很多时候，我在想，也许我把每天桌上足球的时间省下来，周末德州的时间省下来，可以做更多的事情，但是这不是现实的，毕竟我不是机器，需要休息，劳逸结合才是王道。

跟alcatel-lucent这些通信巨头相比，小的互联网公司的一个特点就是快。在ALU，一个稍微的改动从需求的提出，到code，测试，发布给运营商，做得最多的就是review，在review，最终的发布没有个半个月是下不来的。现在半个月，偶的tracer都做好了，后来不是因为前期的需求加上一些未能预计到的因素，花在2周在压力测试上。

小公司上，尝试新事物会比较快，敢于试错，换在alu，这是不能想像的，alu出错，则可能意味着严重的损失。现在，只要不是数据全部出错这种毁灭性的灾难，一切都是可以接受的。

还有就是语言上，以前用c/c++多写，现在改用java，初期还是有些别扭的。用久了，发现java其实还是不错的，不得不承认，在开发工具，开发效率上，比c/c++还是好很多。java里面有很多成熟的类库，可以很方便的用现在的东西搭一些框架，这些在互联网应用里面体现的特别明显。当然C++里面也有很多类库，但是在互联网应用上，还是要差很多的