分布式事务利器——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?没听说过,赶紧百度一下。
58到家多端消息整合之路
经历野蛮发展阶段后,58到家存在众多消息收发场景及不同技术。案例分享总结多个业务场景下消息收发的难点与挑战,梳理各项技术的特点,结合实际业务及研发需求,构建了一套通用消息投递方案。方案建立统一的端到端、端到服务器、服务器到端的消息通道,对业务方屏蔽不同技术的差异,提供消息到达率等核心指标的监控统计。实现业务线能够快速接入各类消息服务的目标。
Tigase手动安装过程
公司要做一个IM系统,现阶段人力资源很有限,产品、研发、测试目前就我一个人。跟领导沟通后决定先采用开源原件tigase先解决有无问题,后续人员到位后进行重构。本文主要介绍生产环境下tigase的安装问题(此次安装是在测试机器中进行,但是周边环境近似生产环境)。
JWT技术解决IM系统的认证痛点
随着业务的发展,多个业务线接入了IM系统,IM系统长连接的安全问题变得很重要。瓜子有统一登录认证系统SSO,IM长连接通道也利用这个系统做安全认证,结构如下图。
基于TimeLine模型的消息同步机制
我们当前的IM虽然进行了微服务化,但是核心的消息投递模式仍然采用下图描绘的方式,参看《一个海量在线用户即时通讯系统(IM)的完整设计》。
TimeLine模型下确保消息有序不丢
通过《基于TimeLine模型的消息同步机制》一文,我们了解到Timeline模型有非常多的优点,也是钉钉采用的消息同步机制。实际工作中,我们也将该模型应用在了C端用户的消息场景中。实施过程中也遇到了一些问题,积累了一些经验。本文将介绍极端情况丢失消息的问题及解决办法。
Redis SortedSet结构score字段丢失精度问题解决办法
项目中采用Redis SortedSet存储用户的离线消息,score值存储的msgid(消息ID)。msgid采用snowflake算法生成,按照时间有序。(参看《一个海量在线用户即时通讯系统(IM)的完整设计》)
瓜子智能在线客服整体架构
瓜子业务重线下,用户网上看车、预约到店、成交等许多环节都发生在线下。瓜子智能在线客服系统的目的是要把这些线下的活动搬到线上,对线下行为进行追溯,积累相关数据。系统连接用户、客服、电销、销售、AI机器人、业务后台等多个角色及应用,覆盖网上咨询、浏览、预约看车、到店体验、后服、投诉等众多环节,各个角色间通过可直接操作的卡片传递业务。
如何高效计算DAU
项目中一直有计算DAU这类的需求,业务开发者往往埋个点,其他是事情就交给数据团队了。如果自己要做一个这样的计数器怎么做呢?一个朴素的想法是通过hashmap实现,时间复杂度是O(1)。这个方法在计数对象较少的情况下还是不错的,但是如果计数对象很多(比如计算独立访问IP),意味着hashmap的key非常多,内存消耗是非常大。
HBase的表结构你设计得不对!
正如我在前面章节强调的,HBase数据模型跟关系型数据库系统有非常大的差异。因此,设计Hbase的数据表的方法和思路跟关系型数据库不一样。设计HBASE表应该在具体业务场景的上下文中回答以下问题
快速理解HBase和BigTable
有关系行数据库经验的人(比如我),在最初接触HBase这样的数据库时,对数据结构的理解容易遇到障碍。会不自觉的将HBase的行、列等概念映射成关系型数据库的行、列。为了加速理解HBase的一些概念,翻译了这篇文章《Understanding HBase and BigTable》(HBase官方文档推荐阅读文章)。
一篇文章掌握常见的网站攻击方式
最近兼职部门的安全接口人,时不时收到信息安全部发过来的漏洞,有些漏洞看得一头雾水(没文化真可怕)。赶紧普及一下常见的安全问题。这篇文章主要描述常见的网站攻击方式(OWASP是世界上最知名的Web安全与数据库安全研究组织,更多安全问题可以搜索OWASP)