Home

好久没写写自己心里的感受了。大概自从毕业工作之后，每天忙很多的事情，就不再有心情去体会一些事情。习惯了忙碌于工作，在这个城市的街头、地铁和公交站穿行，每天想的是五环的房价、今天有没有雾霾和路上堵不堵，只有夜深人静的时候才会想起以前的日子。 想起北航的参天大树，想起以前的同学，想起清华的荷塘，想起校园里美好的日子和可爱的女生，想起晚上安静的校园和校园外的车水马龙。大学的生活确实是人生最美好的几年，让你无论什么时候回想起来都觉得心底柔软、岁月静好。 有时候觉得自己迷失在时间里了。每天早晨醒来，想的都是匆匆逝去的时间和忙不完的事情。停下脚步，听见风穿过的声音，才觉得时间的洪流里面，也有这些许的温存，有难得的避风港，让灵魂停下来歇息一下。哎，我曾经是多么感性的一个人啊… 物是人非。尽量不...

作为获取文件名和文件路径的函数，dirname和basename的签名是： #include <libgen.h> char *dirname(char *path); char *basename(char *path); 之前没注意的地方是这个函数的输入输出都不是const的，也就意味着这个函数调用过程可能会修改char*指向的string内容。所以直接输出一个不可变字符串是不行的，同理，也要考虑这个非const函数会破坏入参。也就是： char *str = “/abc/def”; printf(“%s\n”, dirname(str)); 会core掉。而 #include <stdio.h> #include <lib...

最近在琢磨MVCC和悲观乐观锁的问题，感觉有些以前学习的点没有串联起来，主要是隔离级别和锁相关的，这里总结思考一下： 两阶段锁解决了什么问题 两阶段锁主要解决事务调度的可串行化，保证了调度是正确的。一个简单的例子参考度娘这里。 实现两阶段锁对应了什么隔离级别。 两阶段锁保证了基本的隔离级别正确性，RC之上的隔离级别（包含RC）都需要至少保证两阶段锁。一个例外是如果where条件不走索引的话，是可能全表加锁的，这种情况下mysql为了性能提前解锁了不满足条件的行，参见这里。 各个隔离级别对应的加锁策略。 这个比较简单了： - RU：读加S锁，写加X锁，完成即可释放。 - RC：读加S锁，写加X锁，读锁完成可释放，写锁一直...

工作里遇到一个问题，想把mysql的crc直接封装一下让go来调用，因为查表的crc计算性能实在是不快，对我们这种文件系统的大报文计算来看，crc容易变成瓶颈。大概性能对比如下： 两线程crc32查表 O2优化 time_elapsed:471.474976s total_size_m : 200000.000000M crc rate : 424.200684m/s 两线程crc64指令 O2优化 time_elapsed:24.877853s total_size_m : 200000.000000M crc rate : 8039.278809m/s c这一端的计算比较容易，go的crc默认是查表， 所以存在不兼容的问题。出于兼容和性能考虑，用cgo封装一下。 首先在...

最近在总结一些协议这么设计的原因，比较杂，纯做记录： 选主过程相当于Paxos的prepare过程： 选出的Leader得到了多数派的同意，相当于Paxos一阶段完成，由于当前Term下投过票的Server保证不再接受小于等于当前Term的，所以保证了选主最终只能选出一个。 不同于Paxos的地方在于这一轮Term下，follower除非Lease过期，否则不会发起新的选主，也就是发起Epoc更大的提案。Raft可以认为MultiPaxos的一种应用，MultiPaxos可以认为是合并了Prepare阶段的SingleDegreePaxos. raft读一致性和选主timeout raft协议本身由于主只是续约了follower的l...

上次见刘鹏老师可能还是搜狐实习的时候，后来刘鹏走了，峰扬走了，整个团队改做推荐系统，最后又回到效果广告，算是绕了一个圈吧。买了本计算广告，更多的是给自己一个念想，念念不忘必有回响么。 主要记录几个知识点或者观点： 竞价的历史性作用、gd广告和竞价广告的诞生原因 保量（guarantee delivery）广告相对于品牌广告（CPT），主要解决了流量浪费的问题，CPM的售卖方式相对增加了广告流量的利用率（比如按照性别的售卖，大致可以增加20-25%的收益）。然而保量广告相对来讲对流量的利用并不极致，大部分gd系统都面临超卖或者保守售卖的问题，可能会导致补量或者浪费，在线流量分配和优化也是个比较复杂的问题。所以才有了竞价广告，根据Nash均衡，广告价格是出价方博弈的结果...

今天遇到一个设计上没考虑好的问题，记录一下。 之前Libeasy的逻辑如果一个连接上有超时的报文的话，整个连接会destroy掉。考虑网络拥塞的情况，如果AB两个报文同时在等待发送，A报文先进入发送队列（链表，非TCP发送buffer），B后进入，而A超时时间长，B立即超时，那么清理掉B的待发送报文的时候，如果destroy掉连接，那么本来可以发送出去的A报文就被强制失败了。 考虑这种情况做了一点修改，让超时的报文被清理掉的时候不会destroy连接。这样编码的时候需要指定一个报文被编码出来的buffer是属于哪个会话（session）的，同时记录一下每个session对应的最后一个buffer位置。清理的时候可以从上述位置回溯到不属于当前session的buffer或者到头部为止...

最近其实是乏善可陈的，项目差不多写完，修修补补，提升下性能。其他的事情诸多不顺，看房价蹭蹭的涨，看工资慢慢的爬，感情纠结一团，其他的么，牙疼，估计牙周炎犯了。 然后今天炎泼说要走了，陈闯二话没说也跟着走了，先知先觉的后知后觉的都有各自的想法，只是我比较懵逼，可能最近事情多了，精力都不在这上面。每个人有自己的选择，目前看互联网差不多进入稳定期了，风口还有，但是能飞起来的猪不多了，剩下的人，要么在大公司朝九晚五，要么在创业公司等期权等上市，少数人还追求着理想，不过最后如果没有回到前面两个状态的话，一般是创业去了。 工作几年觉得介于目的性明确和不明确之间吧。做技术的明显分了两派，以KPI为核心的和以兴趣为核心的，很多时候这两个不是不兼容的。目的明确的，一切跟个人发展不相关的都推掉，目的不...