Xargin

If you don't keep moving, you'll quickly fall behind

业务系统错误设计

最近和同事讨论了几句错误设计的问题,感觉有必要写写自己的看法。 举几个例子,一般你的系统在运行的时候可能会有下面这些种类的错误/失败发生: > 依赖组件挂了,可能是 db,可能是 mq,可能是 cache > 依赖服务挂了,可能是别人给你提供的 http/rpc 服务挂了 > 可能是你的依赖方超时了 > 可能是调用方的参数有问题 > 可能是调用方的参数无法正确地通过校验 > 可能是用户的某种操作在业务逻辑上不具有合理性,不能够接着让他执行下去(例如你就给他一天一次抽奖机会,他不知道从哪里拿来的链接或者api又向你发送请求 > 还可能是程序自身出错了,比如数组越界,对字符串和数字进行加和操作,或者是把 null 当成了某种合法的数据结构,通过点或者下标来获取某种属性 上面这些情况都是有很大概率发生的,当这种情况发生的时候,

[译]Kafka Replication

某个群里因为消息队列和丢消息吵起来了,有人觉得 kafka 没有 ack,所以客户端缓冲会导致丢消息。 这理论有点牵强,即使真的丢消息也不会是因为客户端的缓冲问题。刚好之前仔细读过官方讲 Replication 的一篇 Kafka Replication 的 wiki,不是很长,但很详细地介绍了 Kafka 在做 producer ack 和 replication 的一些折衷。周末无事也就顺便翻译如下吧~以后查着也方便。 Kafka Replication High-level Design 为 kafka 加上副本是基于更强的持久性和高可用的考虑。

周末

周末本来准备窝在家里打游戏,惊闻b站大佬要来北京分享,赶紧起床去听课。期间也和其它公司的人聊了聊,感觉收获不少。 B站现在作为国内二次元的门户,聚集了大部分的动漫爱好者,因为业务模型和日本的 niconico 比较像,所以早期也肯定从n站的产品上学到了不少东西(这句是我说的)。从文化衍生出的直播、周边、游戏服务又能够帮助这个站点进一步地造血赚钱,比如现在非常火的FGO。因为这一两年B站关注度变高,所以即使是对二次元没什么兴趣的人也会感觉和b站有关的新闻越来越多了。比如去年在知乎上先后有 flv.js、2233娘竞拍的事情,也是把他们推上了风口浪尖。 很多70后80后可能都不一定会上B站,但是你可能想不到B站也是一个亿级用户的站点了。从09年创立到现在,在技术上他们也经历了从一个创业公司到越来越正规的过程。有很多方面我觉得做得比现在的公司还要好。挑几个值得说的总结一下吧~ Code Review 首先是我来了现在的公司一直头痛的 Code

[译]redis通信协议

Redis 客户端和 Redis 服务器使用 RESP 协议通信,RESP 是 REdis Serialization Protocol 的简称。尽管该协议是为redis设计的,你仍然可以把他用在其它的 client-server 架构的软件项目中。 RESP 协议是下面一些设计原则的折衷: > 实现简单 > 解析(Parse)迅速 > 可读(Human Readable) RESP 协议支持 integer、string、array 等类型的序列化,同时对错误也设计了特殊的类型来进行支持。请求从

sds与二进制安全

在技术群里有人问了这么一个问题,redis的sds不是号称二进制安全吗?但是sdsnew函数里有对strlen进行调用啊。 跟着仔细看了一下源码,还真的是这样: sds sdsnew(const char *init) { size_t initlen = (init == NULL) ? 0 : strlen(init); return sdsnewlen(init, initlen); } 但是说sds二进制安全是说错了么?也不是,我们看看sdslen这个函数: static inline size_t sdslen(const sds s)