小站重新装修,欢迎到访。

别了,我店

我不是一个喜欢变化的人,但作为一个还算有点追求的技术人,终究要面对的就是变化,转眼离职我店已经三个月了,一直想着在此处稍作总结,没成想也是一拖再拖。

今天不展望未来,只简单回顾下在我店两年多的学习和生活。我12年底拿到我店offer,13年初最终决定离开猪厂,成为了一名所谓的基础架构师。首先感谢一面面试官吴总,问的题目都很适合我,也比较庆幸后面面试我的CJ、HL都比较nice。

入职我店后在大数据团队先混了阵子,和SL一起给Hadoop生态主要成员做了件外皮,后来转到同是架构组的老江手下做消息队列相关研发,终于多年以来对于大并发场景的憧憬成为了现实,激动无比。在SOA团队度过了职业生涯至今最充实的时光,所以其实与其说怀念我店,倒不如说更怀念我们的SOA团队来得准确。

先简单记录下下面几位吧。

老江

80后老码农,资历深,功力更深,SOA团队的导师,伟大的精神领袖,难得的好领导,不鼓励加班,LOL水平一般的重度玩家。常见其手捧英文原版或者打印的英文论文死啃,这其实也是我们工作的一部分内容,不过我是没那个毅力啃完一本大部头的。

  • 代表作: hedwig
  • 经典台词: 都别装了,下班了

老董

此人在杭州有套140方,至于其他城市的房子,我就不多说了。另外其和老江一样,生生抛弃了屙粒粑粑几千股,命运就此转折。

  • 代表作: detector
  • 经典台词: 昨天去听了场炒股讲座,不错

常委

码字是副业,其实是一家公司的二股东,小老板,团队里理论上最富有的人。时政野史的首席发言人,翻大墙师(此处请读者自行调整文字顺序),阿波罗重度用户,故得常委一名。

  • 代表作: detector、kira
  • 经典台词: 我不喜欢吃肉

长坚

新上海人,股神,一年只出手若干次,屡次看清大势成功抄底或逃顶,收割起散户无所不用其极,习惯将变量命名为一整句话。

  • 代表作: kira
  • 经典台词: 咱们今天吃龙门客栈吧(众人摇头)

荣新

准拆迁富,典型的狗屎运者,刚在闸北买了套又小又旧的拆迁房,就被并入静安区了,最近听说又要拆迁(天理何在?!)。

  • 代表作: transfer
  • 经典台词: @&#¥)(@#@! (语速太快,总是听不清)

海青

我见过的唯一的新款MacBook用户,因其极其擅长分析各种线上问题,人送外号人肉detector。

  • 代表作: zone-switcher
  • 经典台词: 不详

佳威

上海土著,旅法学者,CTO校友,似乎是我整个职业生涯中面试过的人里唯一一位成功入职了的。

  • 代表作: 不详
  • 经典台词: 我现在公司的架构low爆了

这几年整个行业的人员流动都很快,这几位是共事比较久的,多事之秋,其中有四位已经另谋出路。其他的如老虎、智红等先不多说。

其他的也随便记录下。

意未

公司附近的一家餐厅,想来老板应该是旁边艺术学院的老师,装修机具艺术风格,最有意思的是每天只做一套餐,有兴趣的加微信公众号Artaste_yiwei,可进一步了解其逼格。

周会

周五下午会议室或者必胜客,更新下进度、扯扯淡、吹吹牛、喝喝下午茶。后来加入了一个分享环节,唯一的要求就是分享内容尽量不要与工作内容相关。后来股神一直介绍炒股知识,老江的分享逼格更高,不过我只记得有教怎么看手相,常委主打历史牌,最经典的是详细介绍了古代皇帝的三宫六院建制,我分享过易信的架构以及装修必然被坑的历史教训。

在我店的工作算是比较舒心惬意的,虽然有过几次在高铁上或高速上接到SA电话的黑历史,至于生活,我想,在这个行业,能谈得上有生活,已然算得上不错了。我至今丝毫不避讳对我店的怀念,但人终究是生活在现实中。想记住的太多,反而不知道应该从哪里继续,这里暂时停笔,有缘再补。

合影附上。

1号店的伙计们!

[备忘]记一次使用Btrace排查线上问题

本文仅供博主备忘。

背景

我目前负责我司的分布式消息队列产品,某日,有业务方上报可能发生少量数据丢失,事态紧急,赶紧排查!

验证问题

观察监控曲线,发现15分钟动态监控报表的生产和消费确实有数量上的差异,丢失的不算少。这里要说明一下,一般来说如果生产消费是持续不断的,是很难通过此类报表判断出数据丢失,因为消费是有延迟的,统计会在时间维度上产生错位,幸运的是此业务方的消息是定时发送的,大概是一两分钟一批,消费速度也很快,所以统计曲线看起来就像是一条条抛物线,丢不丢一算便知。

检查各计数器和log

相关计数器正常,log也未发现任何疑点。

思考

服务正常,但消息确实有少量丢失,而且受影响的topic似乎也极少,这个仅从表面看想必是很难看出原因了。考虑到消息的消费先是由LeaderServer分配ID段的,所以我决定祭上神器Btrace,线上抓取分配的ID和ACK表对比,力求找出蛛丝马迹。

动手

脚本如下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@BTrace
public class GetMessageIDGreaterThan {
@OnMethod(clazz = "com.yihaodian.architecture.jumper.common.inner.dao.impl.mongodb.MessageDAOImpl", method = "getMessageIDGreaterThan", location = @Location(Kind.RETURN))
public static void traceExecute(@ProbeClassName String name,@ProbeMethodName String method,String topicName, Long messageId,int size, int index,@Return Long ret){
if(BTraceUtils.compare(topicName,"dmp_user_creative_product")){
BTraceUtils.print(strcat("params","=>"));
BTraceUtils.print(strcat(topicName,","));
BTraceUtils.print(strcat(str(messageId),","));
BTraceUtils.print(strcat(str(size),","));
BTraceUtils.print(strcat(str(index),","));
BTraceUtils.println(strcat("result=>", str(ret)));
}
}
}

其中,messageId是已经分配的最大ID,返回值ret是此次分配的最大ID。理论上,一系列输出应该是连续的。也即上一行的ret和此行的messageId是一致的。事实确实如此。

继续比对ACK表。解析一系列输出,写了个脚本输出了一堆mongo的查询语句,目的是查出哪些段的ID丢失了ack。经对比,一个奇怪的现象出现了,所有长度为264的ID段都丢失了。经检查,此数值乃JVM启动参数之一,即-Dglobal.block.queue.fetchsize,用来配置ConsumerServer批量获取消息的大小。为何这么巧合,丢失的都是长度为264的ID段呢?

表面淡定内心纠结地查了一通,发现了疑点,不是每台机器的-Dglobal.block.queue.fetchsize都一致,但最大的是就是264。这个比较意外,但想了想应该也不会出啥大问题啊。

更加糊涂了。

翻查代码,终于查找到元凶。如下,

1
2
3
4
if (messageIDList != null && messageIDList.size() <= fetchSize) {
//logic goes here
return messageIDList;
}

其中,

1
private final int fetchSize = Integer.parseInt(System.getProperty("global.block.queue.fetchsize", "200"));

问题找出来了,LeaderServer的配置是264,所以ConsumerServer拿到的ID段长度也是264,但本机的fetchSize比264要小,所以被直接忽略了。

那么问题是怎么产生的呢?导致问题的代码看似多余,其实也是一种自我保护。所以问题还是要归咎于配置不一致,引起逻辑上的混乱。那么为什么配置会不一致呢,原来前阵子SA为了方便使用puppet部署,将各种配置都参数化了,效果就是代码部署时,通过对硬件的计算,修改各种参数取值,这样就降低了运维的复杂度。虽然申请了一批硬件配置相同的机器,但是其“软配置”却各不相同,导致有些关键参数未能完全一致,而我又未能察觉隐患,故导致此问题。马上修改配置,重启,解决。

反思

吃一堑长一智,这件事情的教训就是,类似问题很难保证完全避免,但在研发阶段就要多思考会导致问题的场景,及时写注释或记录到文档里。毕竟代码逻辑久了谁都会忘,但注释放那就会时刻提醒你不要犯错。当初如果在脚本的相关参数上备注:必须保证每台机器的此配置取值一致,问题也就不会发生了。

另外一点就是Btrace确实是排查问题之神器,让人无路之时转而柳暗花明。

迁移到hexo,重新开张

过而改之,善莫大焉。

不过,这一年多也不是懒,家事、公事事事操心。如今这博客重新装修下继续营业。后面我会逐渐把这遗失的一段时光写出来,谁让我记性太差。

为了此次重新开张,我换了工具和主题,放弃了jekyll转而启用hexo,主要是因为这个主题我比较喜欢。不过hexo自定义起来绝不轻松,折腾了好久。

还有一个不是理由的理由,之前被美帝子民抢注的jingege.me,终于又回到了我手里!

无论如何,欢迎回来。

1237

博主是一个不是很聪明的码农。完美主义者,强迫症中期。这里会记录一些回忆和点滴,以博为镜。

武器库:

该博客使用基于  Hexo  的  simpleblock  主题。博客内容使用  CC BY-NC-SA 3.0  授权发布。最后生成于 2015-12-11.