本溪人民与三亚人民的心，是比其他东北人民更早的连在了一起的。第一次听说三亚这个地方是刚上小学前后，那时候去三亚的东北人应该远没现在多（当然即使现在我认识的亲戚里好像也极少有去三亚过冬的）。但我所在的小学（本溪最好的小学）和三亚那边有合作，联办个什么小学。两边是同一个校长，一个老太太，早就过了退休年龄但还在干。在本溪，“老侯太太”也算是我们高中校长“老庞”出名之前的全市教育界最知名人物，不过前些年已经去世了。我们小学的老师也有一些去那边教课的。搜了下网上的资料，应该也是很多年前的了，原文如下：七年前，当时的三亚市政府鉴于三亚基础教育极其薄弱的状况，向辽宁省本溪市政府求援。本溪市政府即派当地教学水平较高的本溪师范附小，与三亚市教育局联合创办一所公立小学，支持三亚的基础教育。本溪师范附小是辽宁省的重点小学，在当地享有盛誉。1994年9月，“南北联姻的三亚第七小学正式创立。由本溪师范附小择优选派一批骨干教师来七小管理和任教，本溪师范附小校长侯秀兰兼任七小校长，负责学校的人、财、物及教育教学工作，三亚方面负责教学设施和辽宁本溪老师的工资。本溪的老师们克服种种困难，推行素质教育模式，以务实的教育作风和突出的办学成绩，为学校赢得了一次次殊荣。建校七年，硕果累累。鉴于七小的突出成绩，三亚市与辽宁本溪于1999年6月24日再次续签合同。今年7月，双方联合办学的第二次合同又将到期。三亚七小现有1700 ...继续阅读 (39)

一年前说2016要考虑历史的行程。回过头来看，今年和认识7年交往了3年的妹子领了证；年内房价大涨两波，恰好在两波之间办好居住证，贷款400多万买了房；换了工作，在半制造业半互联网公司做数据库；当了HBase committer。回过头来看，一些事情到底是会被历史的车轮推着走还是会被碾压还需过段时间才能判断。“全面考虑历史的行程”的开局之年结束，2017就是关键之年。要更主动，更有影响力，更健康，更有机会当老板。 ...继续阅读 (41)

HBase作为BigTable的开源实现（之一，但也是应用最广的），其架构应该很多人即使完全没看过HBase的代码也都很清楚，毕竟干这个的几乎没人没读过BigTable的论文。但一个系统除了最基础的架构外还需要有一些细节的优化和实用的功能，很多功能大家就不见得了解了。因此感觉有必要介绍下最近两年HBase新增的一些比较重要的功能。以0.98为基准，在此假设0.98所包含的功能是大家所了解的，毕竟0.98.0是2014年2月发布了的。HBase 1.0.0 在2015年2月发布后，首先最直观的改变是版本号采用了semantic versioning的语义，a.b.c的版本号，a major version变了不保证兼容性（尽量保证可以rolling update），b minor version变了可能会加feature并且对用户公开的API可能会加method（但不会减少，也就是调用API的升级后还能编译，但实现interface的class可能无法再编译），c patch version只负责bugfix。因此现在已经发布了1.0.x、1.1.x、1.2.x三个minor version版本，1.1和1.2分别增加了一些新功能（稍后再说）。而1.0目前已经不再维护，1.1最新版为1.1.7，1.2的最新版为1.2.4，每个分支大概每个月会发一个patch version，等稳定了 ...继续阅读 (38)

在和HBase社区打了快一年交道后，我成为了HBase项目的第55个committer，国内第10个。在当年的一个知乎回答《zhh-2015在分布式系统和数据库领域研究水平和工程能力怎样？》中，我曾经讲过，分布式数据库这个圈子其实不大，外面的人作为用户经常接触，但实际上在圈子里搞这个的人不多。在这种情况下，想判断一个搞分布式数据库的人是否牛逼，主要是看“同行怎么认”，也就类似于学术界的同行评审。对开源的数据库来说，如果能贡献代码说明略懂乃至比较懂，能持续贡献代码并被社区认可成为committer说明非常懂。而现在，PMC已经决定啦，你来当committer。所以，我现在属于HBase官方钦定的懂HBase的人了。当然了，开源的不开源的分布式数据库还有很多，尤其是在大公司。所以，虽然比我更懂HBase的不多，但整个分布式数据库领域，至少在现在国内比我牛的人还是很多的，我也有很多需要接着学习的。之前在一些文章中也提到，其实我刚毕业的时候并不懂分布式数据库，作为一个做业务的服务端码农只是一个数据库的用户，用的是有道根据Google的论文自己造的轮子。后来infra组散伙了，那个轮子没人维护了，我自告奋勇+组织钦点去接触开源的替代品，加上也调研了redis cluster，在那个时候才开始真正接触分布式数据库甚至分布式系统，到现在大概不到三年吧。当时我选的是Cassandra，积累了一些C ...继续阅读 (34)

在民主国家的各种政体当中，其实我非常讨厌美国的政体。因为美国的强大，三权分立在很多时候成了民主的代名词。但实际上并非只有总统制一种制度，即使总统制在操作层面也未必像美国贯彻地这么深。美国的三权分立导致政府和议会相互制衡，美其名曰限制权力，实际上很多时候是耽误事的。何况美国还有两院，两院也一样扯皮。其保护州权的目的大家都清楚，缺陷也显而易见。我觉得行政和立法权对立、两院制缺陷更大，在此不再赘述。而美国的最高法院制度是我最不喜欢的。最高法院既有权判断议会的法案是否违宪，也可以通过打官司来形成判例影响很多人的权益。最高法院9个大法官，总统提名参议院通过，一旦当选除非主动退休否则是终身制。表面上看，这个制度是想让大法官可以无政治、民意上的顾虑来根据客观事实去断案，但实际上因为每个人都有自己的立场、法律判决本质上还是主观的判断，导致这个制度事实上仅仅是一个9人小团体的少数服从多数来决定国家的重大问题。民众唯一能对最高法院施加的影响仅仅在于提名之时，导致很多大法官一干就是一二十年甚至更久（对应的政府也会因而提名尽可能年轻的人）。目前美国最高法院在任的大法官中，最早上任的还是里根1988年提名的。这个大法官只能反映1988年前后美国民众的主流民意，并不一定能反映当前的主流民意。因此，最高法院的人数比是所有人都非常关注的问题，目前因为有人去世导致空缺，左右派比例是4：4。川普上台参议院也在共和党手 ...继续阅读 (38)

左派右派在经济问题上，对于“到底哪些东西是没钱的人也应该有的”这个问题有分歧。左派觉得穷人应该多拥有一些，右派觉得应该少一些。对技术来说，也是分左右派的，左派认为不能通过技术建立优势地位，右派认为有技术就应该用。这都是价值观问题，没啥对错。绝大多数人还是看屁股的。自己没钱就希望大医院便宜一些靠排队搞个号看几分钟病，自己有钱就希望大医院有价格调节机制自己可以不排队就看病并且服务的时间长一些；自己能在网上买票是不会说这对不会用电脑的人不公平的，但一旦自己的票被脚本抢走了就说你这是不公平。加一些因为“进取心”和“圣母心”叛变的。没技术的可能也觉得技术不是不公平，并且去学习新技术；没钱的可能觉得这些都是需要拿钱买，然后努力赚钱。有技术的可能那些不懂技术的人太惨了不应该用技术吊打他们，有钱的人可能觉得那些穷人太惨了得多给福利。这都吵不出结果的。而最大的问题是，人类社会是有规则的，规则可能根据一部分的价值观来制订，有强制性。一个事情对不对，那大家是各自按照自己的价值观来衡量的，没绝对的对错，只有是否符合自己的价值观。但一个事情是否违反规则那是完全客观的了，哪怕你觉得这是恶法，而恶法也无非是这个规则不符合你的价值观而已。比如我可以制定规则不允许程序交易股票期货，也可以制定银行柜台必须是人不能是API，以后AI能写代码了也可以强制要求公司雇人写不能用AI写，就像现在很多地方加油站不允许自助加油。我 ...继续阅读 (37)

在分布式系统中，通过网络通信传递消息来对一些状态达成一致。具体的方式有很多，总体上感觉可以分成三大类，一个是选个master出来，大家在一段时间内都听master的，master提议的大家都听，非master提议的大家都不听，任期到了就通过一种手段重新选举产生master；一个是Paxos，任何人都可以发起提议，通过具体的算法来保证大家一定都能达成一致不会冲突；一种是Gossip，大家每个周期内随机找个其他节点互相同步彼此不知道的状态，从概率上最终一定会收敛成所有节点都拿到最新的状态，只不过节点越多收敛越慢，肯定是最终一致性。今天想讲的主要是第三种，Gossip。Gossip是最终一致性，集群越大延迟越大。但他自然也有他的好处，其中一个是没有中心节点，不存在一个中心节点挂掉整个系统就跪的问题。当然，在现代的分布式系统中，有很多种办法提高中心节点的可用性，而换来的是系统简单、可以实现强一致性，因此很多系统尤其是数据库相关的分布式存储领域，大都还是使用有中心节点的方案，只有Dynamo和对应的Cassandra等用Gossip，无论数据库本身是否火，但这类架构在最近几年已经很少有新的分布式数据库采用了。虽然Gossip这种P2P不太适合数据库，但其他地方还是可以采用的。除了不需要中心节点外，还有个好处是不需要每个节点之间两两直接互通，只要任何两个节点通过其他节点最终都能传递到，也就是一 ...继续阅读 (36)

总结一下最近遇到的一些问题和对应的一些想法。Staged Event-Driven Architecture，简称SEDA，这个词最开始是在Cassandra那边听到的。这个架构的提出是2001年的事情了，用多个线程池而非一个来处理请求。一个请求从开始到结束被拆分为多个阶段，每个阶段用一个独立线程池、并且每个阶段的线程数可以不等，在阶段之间用一个队列连接。每个阶段处理完就扔队列里，下个阶段的线程从队列拉请求去处理。每次处理完一个请求就从队列里拿下个请求来处理。到了2016年，实际上几乎任何server或者server的框架都会用类似的架构，比如一个Web服务器都有如下一些阶段：accept新的连接，根据http协议来parse成对应web服务标准的请求，调用业务实现者的业务代码处理请求、把请求的结果返回给client。不一定每个阶段都是独立的一个线程池、用队列连接，但至少在“业务实现者的业务代码处理请求”这步，是有一个线程池来做的。这样这些线程不断的跑业务实现者的写的代码，前面和后面的任务都是框架来做，可能并不在一个线程池跑。而这个阶段的线程一般也叫worker或者handler。这当然也没啥高端的，不就是线程池嘛。但是在2001年的论文中，单纯的“线程池模型”是限制死了并发请求数的，一旦当前没有任何线程可用，就直接把请求丢掉的（估计20年前的web server都是这么写的？）。 ...继续阅读 (25)

到底还是买房了。12年年初来的北京，实习，一直住微软安排的宾馆，对房租房价没任何概念。后来快毕业了，在龙泽租房。那时看路边的中介写房价32000左右，感觉好贵，买不起，就算有首付，一个月也得还小一万，能买得起的房子得比现在破太多，还是租吧。再后来听同事说才发现买了房后公积金不仅可以一次性提之前的部分并且还可以每三个月把新转进去的提出来的，北京的公积金是24%，上限是人均工资三倍，而当时我公积金有3000+，于是在那天，我突然发现如果首付够，我是买得起龙泽的房子的。于是一直以来我也是把龙泽作为一个买房的底线，要是连龙泽都买不起，那就肯定租房，住更好的。甚至在不买房不能提公积金这个大前提下，夫妻二人两个公积金用来还贷的话，每个月实际付出的月供也就四五千，在当时看甚至和整套房子的租金差不多。当时是租大三居中的次卧，租金1500。再后来为了离公司近，在保福寺桥南与人合租两居，一套5000。再后来在知春路租个开间，4300。今年年初续约，房东说要涨价，念在我是长租，4600签合同，当时的市场价大概5000。而这三个地方目前的租金分别是：龙泽次卧2000+、保福寺桥南两居近7000、开间5600。房租的涨幅非常大，虽然同时期我的工资涨幅更高，但毕竟有码农校招和社招工资悬殊的因素在，如今已经工作三年，未来若干年不算期权的话还真不知道每年的工资涨幅和房租涨幅比哪个高。毕竟房租完全是取决于收入水平的 ...继续阅读 (44)

本文是公司的命题作文，应该会发布在我们组的技术博客中。HBase是一个采用LSM结构的、支持多版本的数据库。与一些数据库解决并发读写问题的mvcc不同（当然HBase也有mvcc），这里的多版本是指在语义层面支持向同一个rowkey+column family+column qualifier中写入多个timestamp不同的value，是暴露给用户的语义层面的多版本，这也是遵循了BigTable的设计。不过HBase的timestamp不仅可以由服务器根据写入时的时间戳生成，也可以由用户指定，因此会额外多一些需要考虑的问题，一些问题至今仍没有很好的解决，本文将描述这些问题，供对HBase感兴趣的人参考，并将在不久的将来在社区的新版中修复这些问题。时间戳是目前HBase中作为判断同一列数据“版本”新旧的唯一标准，读取数据的时候可以指定读取多少个版本，会返回从新到旧的X个最新版本数据给客户端。同时在建表的配置中每个CF可以配置保留多少个版本的数据，超过这个配置后会在compaction时清理掉最旧的若干个版本。因此，如果一个用户按先后顺序分别对同一列写了时间戳为5、4、3、2、1的五个Put，同时保留最新的3个版本，那么读到的会是5、4、3，哪怕这三个其实是最先写入的。 同时因为HBase是一个LSM结构的数据库，在这种结构中，会把删除操作转化为一个特殊的写入，叫delet ...继续阅读 (48)

很久没折腾VPS了，不知道啥时候机器里的yum包已经各种损坏了。所以干脆重新搞了个Linode实例，弄个比较新的Ubuntu，这样装东西方便些，顺便PHP直接搞成7.0，理论上应该节省一点资源，虽然本来也够用。如果能看到这个文章，说明在你那里DNS已经生效了：）  ...继续阅读 (29)

毕业后第二次换工作，决定去小米。现在入职已经两个月了，而博客荒废了仨月。感觉也应该写点东西了。如之前在提离职的时候写的那篇说的，我希望能找到一家能让我在某一个到几个领域成为资深码农的公司。于是选择的时候就非常简单，就是有技术并且有业务的比较大的公司。技术层面，既要有技术积累，也要有高水平的同事；业务层面，要让业务对基础架构有足够的挑战性。其实这年头满足后者的公司比前者多得多，毕竟对大多数互联网公司所做的事情来说，技术都不是决定性的，糙快猛应付下或者直接买服务在很多时候都是可行甚至反而是最佳的，提前对技术做过于超前的储备大概率会浪费（因为互联网创业大概率会死）。反过来，假设一个公司有技术积累又有高水平员工，一旦业务上不去高水平员工肯定会跑只剩下当年比较不错的技术，长期来看技术早晚要落后（前前东家就是如此）。这些原因导致业界很多公司是业务发展非常快技术可能跟不上，去这样的公司也一样有挑战但做的工作未必系统，而且同事的能力也不见得有保障。于是实际上我面的公司不多，最终拒了剩余几家，接了小米的offer。上大学的时候用过一个摩托的手机，当时MIUI应该搞得不久，但已经有一定的口碑，加上国行自带的rom或者CM都各种难用，于是刷了MIUI，当时的感觉MIUI真是领先其他安卓ROM几个身位。所以我小米的账号id是117xxx，比很多小米老员工还靠前。后来换了iPhone5s，也就没再用过MIU ...继续阅读 (38)

Surface Book拿到手已经快半个月了，可以总结下了。买的是国行的i5独显版。独显方便玩游戏，买i5是因为sb的两种CPU性能都挺一般的，i7只比i5多了一点点缓存和频率而已，跑分只高10%，但是贵1500，意义不是很大。至于买国行，主要还是方便保修。其实我已经很久没用Windows了，现在手里的MacBook Pro非视网膜版已经用了三年半，中间用过一段时间双系统玩游戏，后来游戏也不怎么玩就干脆把win7删掉了。完全没用过win8的结果就是直接用win10的话变化还是有点大一些地方得适应下，不过也有不少进步的地方，就是不知道是win8改的还是win10改的。之前用Windows的时候是很少睡眠/待机的，都是直接关机。而MacBook很少关机，都是直接合上盖子待机，打开就接着用。而SB这块做的不是很好，一方面是Windows的问题一方面似乎是驱动的问题，导致基本上还是关机为主。比如经常遇到合上盖子风扇接着转完全不停，打开盖子发现系统也并没有进入待机，于是不得不直接关机了。而且比较奇葩的是感觉开机的时间和待机恢复的时间差不多，只慢一点，也不知道是该说开机很快还是待机恢复很慢……也因为很少待机，之前一直说待机费电的问题我倒没太注意，我甚至怀疑是因为很长一段时间内其实系统并没有待机所以才那么费电的……SB支持人脸识别登录，不知道安全性如何，但至少比较方便，只要不是差得离谱至少可以防 ...继续阅读 (41)

又要换工作了。如业界新闻稿所说，豌豆荚拆分了，而我已经决定不留在拆分后的新公司。提离职的时候实际上是“头都不回”的，因为本来是可以看下新公司给我的期权啊啥的，但是想了想，还是不知道比较好，免得万一以后新公司牛逼了，我还得算“要是不走能有多少钱”什么的……有人留下来有人走，无论留下来还是走，原因都因人而异，对我个人来说，新公司变成资金比之前更紧缩创业公司并不是我离开的真正原因，或者说本来如果不进行拆分我年后也是打算看看新的机会的。因为我知道我到了再次转型的时间了。虽然我13年才毕业，但来帝都快4年了，这比很多12年毕业的外地学生来的还要久。回过头来看，一共在三家公司呆过，虽然都不算很久，但是收获都很大。第一家MSRA。首先不用我租房子不需要让我刚出校园就体验民生疾苦，还让我以最小的代价（不需要花时间读研读博）来尝试或者说“玩”一下科研，而且相对于国内很多研究生的情况来说可以说是体验到了“纯粹的科研”，而且还小有成果（论文）。从入职学习接触这个领域拼命看论文（还让我半年内六级的阅读分数提高了50分，虽然还是没过……）、到后来参与微软内部的review/交流，再后来准备CVPR熬夜写论文+rebuttal，再后来帮别的项目准备会议熬夜写代码，最后离职后毕业前自费去了美帝体验了下学术会议，各种东西都体验了一遍，除了最近被媒体提到的“公款参加学术会议”我都体验过了……第二家有道。有道没那么大 ...继续阅读 (36)

作为一个自认为算不上是锤粉和罗粉的人，第一次去现场听老罗讲相声。再顺便讲讲对锤子的看法。在现场的感觉和看网络直播自然是不一样的。买的600元票，大概是这样的角度和位置：不知道是不是苹果开的头，现在所有手机厂商都开发布会。至少在国内来说，能单纯让人们无论是否买手机都关注发布会的不多，但老罗做到了，这是很大的优势。但关注度当然不等于销量，在网上火的牌子，这年头只有“便宜”才能转化为销量。之所以强调“在网上火”，是因为线下的渠道是另一个世界，或者说非年轻人买手机是另一种情况。锤子花了一年半的时间做T2，不知道比最开始预期到底晚了几个月。晚的这几个月换来了大家所看到的东西——无断点全金属中框、无电源键、音量键和sim卡槽合体、更轻的重量。在整体样式和T1差别并不显著的情况下，这是我能看到的主要区别。其中可能无断点的金属中框是最难的，没准是真正导致这么晚才推出的原因。漂亮吗？漂亮。值吗？不知道。在业界大多数厂商没这么做的情况下，锤子这么做必然不能说其能力不足从而做得慢，只能说如果不要这个特性能早发布好几个月赢得很多时机。但是有了这个特性后，更强的设计感也一样会赢得更多用户。我对这个问题个人看法是，提早几个月发布的话，T2肯定能卖更多，但那样的T2不够好。作为一个普通用户我个人我并不在乎发布的早晚，甚至不太在乎价格，我更在乎品质，而T2这个无断点的中框，就像T1的简洁版听筒，能让我单纯因为一个 ...继续阅读 (34)

本文的起因是微博上@纯银V 发起的针对豌豆荚一览的产品讨论，但本文不主要讨论这个话题。都知道现在是个信息爆炸的时代。不仅获取信息的来源越来越多、越来越方便，每个来源能提供的内容也越来越丰富。这一切归功于互联网的发展——并不只是技术的发展，还有产品的发展。从过去定期看报纸、电视新闻，到后来用电脑上网看新闻，再到手机也能上网，再到智能机允许服务器主动给手机推送通知发新闻，不仅信息的及时性有了保障、数量有了保障，甚至很多时候不看都不行，是否弹窗也成了不少用户评判某个产品是否流氓的标准。不同的人对信息的偏好程度是不一样的，这里说的不是话题——比如体育还是娱乐还是科技还是财经——而是内容的性质。在某个事件刚发生的时候可能信息只有一句话，在发生一小时后可能是一段话，在发生几个小时后是一篇几百上千字的文章，在发生几天甚至几周后是一篇非常长的深度文章。总体来说，“憋”得越久，内容越丰富。就像从前只能写信的时候一封信会说很多东西，后来能打电话的时候电话只聊几件事，现在有了微信可以一天聊好几次每次只有几句话。但是，人们到底对很及时又很粗糙的信息有多大的兴趣和获取的意义呢？十多年前的911，据说国内第一个发布消息的是新浪网，距离第一架飞机撞世贸大楼10分钟左右，考虑到当时的互联网还没有主动弹窗的功能，人们上新浪看到这个消息可能又会晚很多，甚至很多的流量其实是靠口口相传这个消息然后大家才去上网看来龙去脉。 ...继续阅读 (18)

如不少人所看到的，Codis发布了3.0的alpha版。这个版本本来叫2.1的，但是因为改动比较大，直接改名叫3.0了。Codis发布至今一年有余，我参与Codis项目也有大半年，在这个继往开来的好日子里，有必要讲讲很多想法——只代表我个人的想法。Codis是Redis的集群解决方案，这意味着他基于Redis，继承了Redis的部分优点，也继承了部分缺点。换句话说，让Redis得到了水平扩展的能力，但依旧无法突破Redis自身的诸多局限性。以及在Github中的提问中发现，其实不少人并没有严格区分Redis和Codis，会觉得这是一种东西，所以很多时候问的问题其实是Redis的问题。在Codis之前、之后，除了在client自行实现分片逻辑之外，无外乎还有两种方案，twemproxy和官方的redis cluster，我在《离职系列文章之redis cluster使用经验》中提到过redis cluster的一些问题，不过现在回头来看并没有完全解释清楚。前不久在Codis的README中我添加了一个表格，如下：CodisTwemproxyRedis Clusterresharding without restarting clusterYesNoYespipelineYesYesNohash tags for multi-key operationsYesYesYesmulti-k ...继续阅读 (85)

Cassandra系列文章的第三篇。在第一篇文章中提到过，Cassandra的每个节点都存储从key到node的路由信息，而且这个路由表是整个集群共同维护、修改的而非某个master修改的。如果有一个master来维护，那么想怎么分就怎么分，每个节点读取这个配置即可。但如果没有这个中心节点，相当于每个节点自己维护自己的路由配置，那么一定要保证根据一个特定的集群状态，所有节点计算出来的结果是完全一样的。并且不仅要计算自己应该存什么，还应该计算别人应该存什么，因为客户端连任何一个节点都能请求任何数据。换句话说，每个节点根据一个特定的集群状态计算出的某个节点的sharding信息应该是完全一样的。为了达成这个目标，首先集群中的每个节点获得的集群状态应该是一致的，其次根据这个一致的状态应该用同样的逻辑来进行计算。输入和计算逻辑一样，才能保证输出一样。并且如果集群的状态发生变化时，比如有机器挂掉、新增了新机器等，为了数据的一致性，应该尽量保证路由信息不变，如果路由信息不得不改版，应该做到尽量安全切换，防止数据丢失。同时因为Cassandra是CAP中的AP系统，路由信息切换不能以暂时无法访问失去可用性为代价。对第一个目标，获得一致的集群状态，Cassandra使用gossip协议维持其一致性。Gossip协议是一种无中心节点的分布式系统中常用的通信协议，akka等系统也用。简单来说就是每个节 ...继续阅读 (35)

Cassandra系列文章的第二篇。在说CQL之前，得先说一下BigTable。说BigTable前，得说下NoSQL。在说NoSQL之前，得说下关系型数据库。关系型数据库是什么，其实我也说不好，甚至搜了一圈定义也没有搜到一个恰当的中文定义，好在搜到了个英文的定义觉得比较恰当：Relational database management systems (RDBMS) support the relational (=table-oriented) data model. The schema of a table (=relation schema) is defined by the table name and a fixed number of attributes with fixed data types. A record (=entity) corresponds to a row in the table and consists of the values of each attribute. A relation thus consists of a set of uniform records.也就是说，关系型数据库的数据模型是基于“表”的。表作为一种二维结构，每行是一条记录，并且每条记录都互不相同；表的每列是这条记录的一个属性。此外，关系型数据库还应该支持 ...继续阅读 (63)

想写的Cassandra系列文章的第一篇。本文的中心思想是：不谈需求场景只谈利弊是耍流氓；只谈利不谈弊是臭流氓。分布式数据库，自然是相对于传统的单机数据库。从传统的单机数据库到多机分布式数据库无非是有两大类需求：单机在性能或数据容量上扛不住；单机有单点问题，一旦挂了系统就挂了甚至数据都丢了。这两个核心需求决定了分布式数据库的根本目标有两个：多个节点承接读写请求，从而加大整体性能；多个节点存储数据，每个数据存不止一份从而防止丢数据并且提高整体的数据上限。最简单直接的办法是，把单机数据搭很多个。每个节点处理一部分数据，从而加大整体读写吞吐和数据上限；同时提出“主从”概念，多个节点处理同一批数据，这样其中一个节点挂了另一个节点马上顶上。无论Mysql、redis、mongodb都有类似的方式可以将单机数据库扩展成集群。另一种新思路绕开了单机数据库，从设计上便实现分布式，是天生的分布式数据库。Google基于GFS设计了BigTable，因为GFS是分布式文件系统因此只要把数据持久化在GFS上便实现了第二个目标既数据存多份；因为GFS可以通过rpc调用读写整个文件系统上的任何数据所以每个BitTable的节点理论上都可以处理整个数据库的请求，从而实现了第一个目标既多个节点可以承接读写请求。开源的HBase在总体思路上山寨了BigTable，后文用HBase代指这种设计。还有一种思路，不基于 ...继续阅读 (24)

本文作为一个提纲，分篇写好后把链接帖在这。分布式数据库的取舍——Cassandra的选择及其后果本文将列出分布式数据库在设计时需要考虑取舍的若干特性，并介绍Cassandra选择了哪些特性、放弃了哪些特性。CQL——Cassandra does not have SQL本文将介绍Cassandra的query语言，并介绍一些特殊的系统自带表以方便后续讲解。Gossip、DHT和传说中的W+R>N本文将介绍Cassandra的基石——gossip和一致性哈希，并介绍依照两个特性设计的集群带来的优势和问题。存储引擎解析完一条CQL语句后，是如何插入或查询的。Tombstone单独一篇讲下这东西，这是个坑轻量级事务其实就是单行CAS后续部分未完待续 ...继续阅读 (66)

最近公司组织一个在亚马逊买买买的活动，于是十分无聊的买了一盒乐高，选了个不太贵的里面适宜年龄最大的…… 包装盒写是8-14岁，8岁以上我理解，不知道为啥不让24岁的玩…… 里面三袋零件，一个说明书。 第一袋。零碎的小部件专门有个小袋子装。  第一袋拼完是这样的。 第二袋。  基本的飞船型出来了，一共三个小人。     第三袋是四个机翼，合一起就都搞定了。 然后飞船前部那个圆形门的下方有俩红色的棍子插里面。组装第一袋的时候飞船的后面有个东西可以转，当时还好奇是啥，后来整体拼完发现转那个东西能让前面这俩小棍发射出去，实现了飞船打炮的功能，还挺远的差点射丢…… ...继续阅读 (69)

最近刚发现Cassandra计划在未来支持“RAMP事务”。这是SIGMOD2014的论文《Scalable Atomic Visibility with RAMP Transactions》引入的概念。本文算是读论文的笔记吧。RAMP的全称是“Read Atomic MultiPartition”，就是分布式的“读原子性”。文章定义出一种新的隔离性——Read Atomic Isolation。简单说就是在分布式数据库中一个对多行同时写入的事务，需要保证其他客户端在读取事务发生时要么可以见到其修改的所有行，要么都见不到。相对来说，ACID中的A是描述的是“写原子性”，写入多行的事务要么都成功要么都不成功。而Cassandra已经通过logged batch来实现了写原子性。读原子性只保证了单个写入事务在其他读取事务面前的原子性，但是多个事务同时写的话不保证隔离性。所以RA隔离性的事务可以满足诸如“不能在某个时刻同时读到A的好友里有B，而B的好友里没A的状态”这样的需求，经典的“银行转账”类跨行事务的需求因为可能涉及到并发写，RA隔离性是搞不定的。这就意味着RAMP事务只满足了一部分需求，当然性能也会比满足大部分需求的要好。在介绍算法前，论文对场景也做了一些限制，如不同client的事务不会互相阻塞对方、每个节点挂了都只影响其保存的数据的读写而不应该影响其他节点上数据的读写。文章称 ...继续阅读 (52)

今天讲一下分级基金好了。虽然我也是半个月前才知道这玩意的。基金的定义很好理解，就是把钱交给别人来帮你投资。对股票型基金来说，就是让别人帮你炒股。其实我一直觉得对大多数散户来说，其实买基金是最好的选择，原因很简单，就是很多散户真的是啥都不懂。而分级基金，是在基金上衍生出的一个东西。他基于普通的基金，称作母基金，并把2份母基金拆成1份A基金和1份B基金（其实还有其他比例，这里用最常见的1：1来举例）。母基金（后面称作C）的净值就根据其投资的股票涨跌而涨跌，和普通股票基金一致，而AB基金的净值是这么定义的：A基金的净值发行那天为1，之后按日付息每天增长一点点，年利率为一年定期存款利率+一个固定的数（一般是3%或者3.5%之类的）。B基金的净值为，当天2份母基金的净值减去1份A基金的净值。因为AB基金就是由母基金拆分而成，如果母基金的净值为C，那A+B肯定等于2C。这个定义意味着什么呢？道理很简单——就是相当于A基金拿固定收益，而B基金的持有者拿走A基金对应的股票收益，或补贴A基金对应的股票亏损。也就是说，A基金是一个稳定收益的基金，而B基金是带杠杆的股票基金。而杠杆率会随着AB的净值比例的不同而不同。如果A净值为1，B净值为1，那么B的杠杆是2倍，也就是说母基金涨了5%，B就可以涨10%，跌也如此；如果A净值为1，B净值为0.5，那么杠杆是三倍，因为母基金净值是0.75，他涨10%，变成 ...继续阅读 (42)

今天说说我对股票的看法。这并非一个扫盲/科普贴。股票是零和博弈吗？我认为不是。零和博弈的定义是有人获利意味着必然有人损失，且幅度相当。但股票不满足这个特征。我们举这样一种极端情况：有一个股票，以10元发行1亿股，即融资10亿。然后这只股票一直慢慢涨，每个月涨1块钱，涨到20块钱的时候突然宣布回购这部分股票，公司以25元的价格收购这一亿股。无论在任何时间点买、卖这个股票，对于买这个公司股票的所有人来说，都赚了，没任何人赔钱。但是钱是不可能无中生有的，钱从哪来？就是公司以25元回购股票，公司需要出25亿。买股票的人累计一共赚了15亿，但能说公司是募集10亿资金再花25亿回购因此赔了15亿吗？不能。因为这买股票的25亿可能是因为当初融资10亿后扩大生产带来的巨额利润的一部分，对公司是有很大帮助的，而回购的目的也是回馈当初帮助了公司的股民。不少公司因为上市时间足够长，股票分红的累计花费都超过了当初募集的资金。所以谁都没亏，也就不能说股票是零和博弈。当然公司回购股票也不多见，甚至不少公司还迟迟不盈利。可这依然不意味着股票是零和博弈。只要一个股票一直是涨的，那么所有买的人都会赚，实际上外来的资本推高了成交的价格，最后买的人还未卖掉股票因而未获得实际的收益。但不能说这个人现在是亏损了x元的。因而只要永远保证不断有外来资本进入（或者公司的利润分红），买这个公司股票的人都不会亏，而一家公司可能已经上 ...继续阅读 (44)

上下班坐地铁算上走路大概要50分钟（当然有接近10分钟是因为东升科技园的门开的比较奇葩），而打车不到半小时（不算额外需要5-10分钟等车来）。之前基本上只会因为起晚了或者上午有事情而打车，但因为“人都是越来越懒的”和“由奢入简难”两个公理，每天上班打车的概率越来越大了，甚至感觉离每天上班都打车不远了。最开始打车还是叫快的或者滴滴的出租。但后来发现各种专车不仅车好还便宜，于是现在打出租只是为了要发票报销。最近一个月分别试了神州专车、滴滴快车、Uber三家。神州专车是公司雇人开公司的车，相对来说车况比较好，或者说车况的下限水平至少在现在比较高，以后就不知道了，毕竟不太可能说这些车用两三年就报废吧。至于服务，都是公司雇员也算是个特色，群发短信广告的时候直接说“没有私家车，没有性骚扰”……但是我倒是没觉得比其他的强太多，毕竟这玩意也没啥好不好的，就是开车而已。倒是上周日坐神州专车，那个司机过一会有送机场的预约订单，然后看时间有可能赶不上就把我们提前扔下了，少收我们4km的钱就把我放在一个地铁站旁边……神州专车的收费标准比较高，但因为充100送100，相当于打5折，所以里程和时间的费率和其他两家基本一样，但是因为有个15块钱的起步价，相当于每单固定多7.5元。总体的感觉就是一旦取消五折优惠必然没人坐。之前说五折优惠充值截止到5月底，最近果然说再延长三个月。滴滴快车据说国内滴滴的专车份额是最高 ...继续阅读 (39)

因为redis是单线程，请求都是串行，所以协议的设计很简单（陋），client也假定数据库是单线程所以也比较简单，比如有了pipeline后完全没有搞异步接口的必要，其他语言不知道，Java的jedis应该是没有的，全是同步阻塞的。但一旦扩展成多线程，比如codis，一个client在一个业务逻辑内一次读多个key，在基于当前的redis client的接口的情况下，因为协议串行导致必须按顺序返回给客户端，又因为proxy的下层是多个slot、多个redis，不能用pipeline，所以按照目前的实现，client直接mget多个key，或者pipeline连某个proxy，只能串行分发到下面处理，网络ping-pong的次数显著增加，很可能会导致反而比单redis还慢。当然，redis官方的cluster，直接把pipeline屏蔽掉了，因为要直接在client算slot请求对应节点。所以只要client没有自行搞出异步的接口，无论codis还是官方cluster在同时请求多个key的时候都是个悲剧。对codis来说，目前的解决方案只能是自行搞异步接口，请求N个key由client分在M个connection去请求，M越多甚至可能M=N时最快，但client就需要开很多个connection了。如果改codis的proxy，也是可以搞的。最简单的实现方式就是每个connectio ...继续阅读 (47)

除了redis这类单线程的数据库，一般的多线程数据库在读写数据的时候必然会涉及到资源的抢占或同时操作一行数据带来的版本控制问题。说白了就是，某次读可以读到哪些写、需要屏蔽哪些写、需要暂时阻塞住哪些请求。于是就需要将读写请求维护出一个“顺序”来。Cassandra不需要太多的保证读写顺序，因为最后都是靠时间戳控制版本。需要考虑顺序的主要是涉及到MemTable需要switch或者flush的时候保证不会因为MemTable被清空而导致读写失败。在2.0和之前的版本，直接通过 ReentrantReadWriteLock来加锁维护，读写操作都是读锁，切换MemTable是写锁。在2.1开始用了一个OpOrder的概念来无锁地控制顺序，只需要在需要控制顺序的地方用jdk7的新语法糖来获取一个对象并自动close：try (OpOrder.Group op = writeOrdering.start()){ //do anything }若干个通过这种方式维护的操作被囊括在一个Group内，每个Group内部通过cas维护一个原子计数器，可以理解为start一次+1，close一次-1。需要在若干次操作的序列中制造一个间隔点时——比如当MemTable需要flush时，确保某次写入及之前的读取还可以写入这个MemTable，等都写完了才flush，并确保下一次写入就需要去写其他的M ...继续阅读 (74)

离职“系列文章”只写一篇肯定是不对的……前文写了Redis集群之后，大家纷纷表示我在吐槽公司太穷机器挫，其实我真不是故意要吐槽的……于是很纠结写完Redis之后要不要写Cassandra，因为Cassandra用的机器更挫，直到离职前不久才换了几台新机器……从去年3月开始调研依赖，接触C*也有一年多了。中间写过一些文章，但总体上不是很系统，而且其实也不是很确定写的是不是一定正确；一些是读代码之后的笔记，主要是针对2.1的。所以在这个离职的欢乐祥和的时刻，想跳过细节谈经验和感受。当然我觉得我写这种文章也是有局限的，因为除了C*之外，其他的开源分布式数据库（尤其是HBase）都没用过，所以很难用实战来对比说到底哪个更好、哪个适合什么场景、哪个坑更少。本来是想接着像前文一样先说技术背景的。但是写了上千字的历史故事后看了下感觉对文章主旨没啥帮助，而且怎么看怎么还像是在吐槽，于是就都删了，直接进入正题……当然，阅读本文需要一定的Cassandra基础，比如数据模型、大概的原理等等。入门的东西就不太想说了。Cassandra是靠时间戳谁大谁赢来维护版本的，这个时间戳在初期是由client提供，后来变成默认由接受client请求的节点提供，同时可选由client指定任意一个timestamp。有些地方说这属于最终一致性，有些地方说看W+R和N的关系，大于是强一致，小于等于是最终一致性，我觉得都不 ...继续阅读 (75)

最近在看选举中的谋略与博弈这本书，全书有点长，分为问题篇、方案篇、现实篇三部分，围绕美帝的选举讲了很多东西。最近看完了第一部分，收获还是挺大的，跟之前对选举的一些认识结合之后更容易清晰的去思考。因为不知道啥时候能把后两部分读完，因此先把第一部分的读后感写了。首先是个文中提到的例子。假如有个1公里长的沙滩，上面建两个冰淇淋店。假设所有游客都想买冰淇淋、沙滩的游客是均匀分布、游客只去离自己最近的冰淇淋店买冰淇淋，那么从游客的角度讲，两个店如果分别建在250米处和750米处，对游客是最方便的，游客最多走250米就能到一个最近的冰淇淋店。但是两个冰淇淋店的老板只会想着让自己多赚钱，所以其中一个店如果把地点往中间挪，那么中间那段沙滩的游客就会有更多人来自己的店，而自己那侧的游客虽然需要走更远的距离但还是会来这里。因此越往对方的店靠近，自己接管的范围越大赚钱越多。最后会如何呢？显然平衡的状态只能是，俩店都开在沙滩正中间，每家管一半。在选举中也如此。假设不考虑更多复杂情况，只假设选举的倾向是价值观左右来导致的一元因素。那么左派政党和右派政党到最后一定都变成一个中间形态的政党才能最大化支持度。但是，任何一个“两党制”的国家本质上其实是多党制，只是因为历史、选举规则导致只有两个大党派才能执政，并不是不允许更多的党派参与选举。沙滩也没要求只能有两个冰淇淋店。因此那个只能在正中间买到冰淇淋的沙滩一旦加入 ...继续阅读 (90)