-
编辑 删除
分布式事务利器——RocketMQ事务消息的启示
我们以一个转帐的场景为例来说明这个问题，Bob向Smith转账100块。这个列子在瓜子也有很多实际场景映射，如：车源状态变化，订单状态变化，金融放款，物流运输……
-
编辑 删除
事务注解（@Transactional）引起的数据覆盖故障
车辆交付履约流程上两个节点（工程项目）A和B， A修改一条数据记录item（工单），然后发消息给B，B也会对item进行修改。故障现象，有时候（不是必现）感觉A没有成功修改item这条数据，而日志显示A修改成功了数据item！
-
编辑 删除
IM系统海量消息数据是怎么存储的？
现在的IM系统，消息都要落地存储。这样如果接收消息的用户不在线，等他下次上线时，能获取到消息数据。消息漫游包括主要两种场景，（1）用户新安装IM软件，要能看到以前的聊天记录（2）聊天软件有PC版和App版，在App上聊的天，打开PC版要能够看到
-
编辑 删除
10分钟弄懂Raft算法
分布式系统在极大提高可用性、容错性的同时，带来了一致性问题（CAP理论）。Raft算法能够解决分布式系统环境下的一致性问题。我们熟悉的ETCD注册中心就采用了这个算法；你现在看的这篇微信公众号文章，也是保存在基于Raft算法的高可用存储服务器中。
-
编辑 删除
一个海量在线用户即时通讯系统（IM）的完整设计
真实生产系统的模块拆分比《完整设计》一文中要复杂许多。《完整设计》只在反应IM系统最核心大功能点之间的关系，便于没有经验的读者能够快速上手进行IM设计和开发。
-
编辑 删除
ID生成策略——SnowFlake
某个项目采用了数据库（MySQL）自增ID作为主要业务数据的主键。数据库自增ID使用简单，自动编号，速度快，而且是增量增长，按顺序存放，对于检索非常有利。
-
编辑 删除
微服务拆分到什么粒度合适——康威定律
微服务这个概念一直很火，现在ServiceMesh概念更火，最近我经手的多个项目也都采用微服务的方式开发。但实践发现，当一个RD同时开发超过2个微服务的时候，出现bug或故障的概率会提升。我现在看项目的时候会不自觉的关注工程服务拆分个数和研发人数的比值。虽然这么做，我却说不出来个所以然，也没有找到一个理论依据。
-
编辑 删除
HttpOnly是怎么回事？
最近配合公司安全团队开展一些工作，安全团队建议，内部系统（用户端系统有跨域需求，其他方式解决更合适）对接SSO建议开启HttpOnly。HttpOnly？没听说过，赶紧百度一下。
