技术活动 | 有赞 PaaS 创新技术交流 meetup - 存储与搜索(已结束)

活动背景 有赞 PaaS 团队想通过定期联合不同技术公司举办 PaaS 创新技术交流 meetup, 致力于打造一个优秀活跃的杭州技术交流圈, 提升杭州技术圈的整体实力和影响力。 Youzan PaaS Innovation Meetup 将会定期邀请各地优秀的技术讲师来杭州分享一些相关主题干货。PIM@HZ 期望保持小规模(50人)的深度交流, 打造技术的干货盛宴。 活动亮点 分享有赞在大规模存储和搜索方面沉淀的实践经验 现场正式开源有赞的一个重量级项目 邀请了一位PingCAP重量级嘉宾揭秘TiDB最新的改进和特性 以聊天的形式和讲师零距离深度交流…

Read More

How we redesigned the NSQ - 其他特性及未来计划

在系列文章前面几篇中,介绍了NSQ改造的过程和几个基础特性,本文中我们继续介绍几个高级特性及其使用场景,这些都是结合有赞业务场景总结提炼出来的重要功能。 NSQ拓展消息格式的设计 有赞中间件在NSQ中引入了支持拓展内容的消息格式,通过支持拓展的消息格式。业务方能够在消息体外定义额外的数据,拓展了应用功能,支持更多的场景。 相比较于Kafka等消息中间件,NSQ的消息格式在内容和数量上较为简单。一条消息除了基本的元数据之外,其余内容为消息体。消息的元数据主要包括了消息在服务端产生时的时间戳,服务端对于该消息的下发次数,消息ID。Kafka消息格式(record batch,control record,record)中出现的部 分元数据例如压缩格式(…

Read More

How we redesigned the NSQ - NSQ重塑之详细设计

之前的 文章 讲述了我们重塑NSQ的目的和目标, 接下来我们将详细描述下每个功能的具体技术细节. 重构后架构图 首先, 看一下重构后的整体架构图: 原来的几个NSQ组件大部分功能是复用的, 图中新增的就是元数据存储服务-etcd, 以及数据同步和HA处理逻辑. 改造topic queue 为了增加副本和其他特性, 首先需要改造的就是nsq的topic数据写入方式, 要保证数据最终落盘, 才能继续后面的改造. 所以我们第一步重构数据写入逻辑, 这块逻辑本身并不依赖分布式功能, 可以独立重构. 数据落盘 原版的topic写入流程是通过golang里面的chan来做的, 只有超过chan容量之后, 才会落盘. 但是chan有几个缺点, 首先是内存数据,…

Read More

如何做一个靠谱的发号器

为什么需要一个发号器 在使用数据库时,表的主键经常会使用数据库的自增(auto_increment)来产生。这当然很方便也很高效。但是使用自增也会带来一些麻烦。如果从一个数据库以外的地方,也就是发号器来产生全局唯一 ID,这些问题就可以得到解决,生活就可以更美好。 难以适应分片场景 在采用数据库分片时,如果使用数据库自增 ID,不同分片上会产生相同的 ID。单靠 ID 无法唯一标示一个对象,还需要额外加上分片字段才行。如果需要将 ID…

Read More