关闭

消息总线能否实现消息必达?

一、缘起 任务、延迟消息都放在内存里,万一重启了怎么办? 能否保证消息必达?   今天就简单聊聊消息队列(MsgQueue)的消息必达性架构与流程。   二、架构方向 MQ要想尽量消息必达,架构上有两个核心设计点: (1)消息落地 (2)消息超时、重传、确认   三、MQ核心架构 上图是一个MQ的核心架构图,基本可...
阅读(75) 评论(0)

消息总线真的能保证幂等

一、缘起 如《消息总线消息必达》所述,MQ消息必达,架构上有两个核心设计点: (1)消息落地 (2)消息超时、重传、确认   再次回顾消息总线核心架构,它由发送端、服务端、固化存储、接收端四大部分组成。 为保证消息的可达性,超时、重传、确认机制可能导致消息总线、或者业务方收到重复的消息,从而对业务产生影响。   举个栗子: ...
阅读(36) 评论(0)

1分钟实现“延迟消息”功能

一、缘起 很多时候,业务有“在一段时间之后,完成一个工作任务”的需求。   例如:滴滴打车订单完成后,如果用户一直不评价,48小时后会将自动评价为5星。 一般来说怎么实现这类“48小时后自动评价为5星”需求呢?   常见方案:启动一个cron定时任务,每小时跑一次,将完成时间超过48小时的订单取出,置为5星,并把评价状态置为已评价。 假设订单表...
阅读(26) 评论(0)

10w定时任务,如何高效触发超时

一、缘起 很多时候,业务有定时任务或者定时超时的需求,当任务量很大时,可能需要维护大量的timer,或者进行低效的扫描。   例如:58到家APP实时消息通道系统,对每个用户会维护一个APP到服务器的TCP连接,用来实时收发消息,对这个TCP连接,有这样一个需求:“如果连续30s没有请求包(例如登录,消息,keepalive包),服务端就要将这个用户的状态置为离线”。   ...
阅读(40) 评论(0)

到底什么时候该使用MQ

一、缘起 一切脱离业务的架构设计与新技术引入都是耍流氓。   引入一个技术之前,首先应该解答的问题是,这个技术解决什么问题。 就像微服务分层架构之前,应该首先回答,为什么要引入微服务,微服务究竟解决什么问题(详见《互联网架构为什么要做微服务?》)。   最近分享了几篇MQ相关的文章: 《MQ如何实现延时消息》 《MQ如何实现消息必达》 ...
阅读(21) 评论(0)

一分钟了解索引技巧

花1分钟时间,了解聚集索引,非聚集索引,联合索引,索引覆盖。   举例,业务场景,用户表,表结构为: t_user( uid primary key, login_name unique, passwd, login_time, age, … );   聚集索引(clustered index):聚集索引决定数据在磁盘上的...
阅读(88) 评论(0)

多key业务,数据库水平切分架构一次搞定

数据库水平切分是一个很有意思的话题,不同业务类型,数据库水平切分的方法不同。 本篇将以“订单中心”为例,介绍“多key”类业务,随着数据量的逐步增大,数据库性能显著降低,数据库水平切分相关的架构实践。   一、什么是“多key”类业务 所谓的“多key”,是指一条元数据中,有多个属性上存在前台在线查询需求。   订单中心业务分析 订单中心是一个...
阅读(67) 评论(0)

多对多业务,数据库水平切分架构一次搞定

本文将以“好友中心”为例,介绍“多对多”类业务,随着数据量的逐步增大,数据库性能显著降低,数据库水平切分相关的架构实践。   一、什么是多对多关系 所谓的“多对多”,来自数据库设计中的“实体-关系”ER模型,用来描述实体之间的关联关系,一个学生可以选修多个课程,一个课程可以被多个学生选修,这里学生与课程时间的关系,就是多对多关系。   二、好友中心业务分析 好友...
阅读(59) 评论(0)

1对多业务,数据库水平切分架构一次搞定

本文将以“帖子中心”为例,介绍“1对多”类业务,随着数据量的逐步增大,数据库性能显著降低,数据库水平切分相关的架构实践: 如何来实施水平切分 水平切分后常见的问题 典型问题的优化思路及实践   一、什么是1对多关系 所谓的“1对1”,“1对多”,“多对多”,来自数据库设计中的“实体-关系”ER模型,用来描述实体之间的映射关系。   ...
阅读(83) 评论(0)

MySQL的or/in/union与索引优化

假设订单业务表结构为: order(oid, date, uid, status, money, time, …) 其中: oid,订单ID,主键 date,下单日期,有普通索引,管理后台经常按照date查询 uid,用户ID,有普通索引,用户查询自己订单 status,订单状态,有普通索引,管理后台经常按照status查询 mon...
阅读(38) 评论(0)

MySQL冗余数据的三种方案

一,为什么要冗余数据 互联网数据量很大的业务场景,往往数据库需要进行水平切分来降低单库数据量。 水平切分会有一个patition key,通过patition key的查询能够直接定位到库,但是非patition key上的查询可能就需要扫描多个库了。 此时常见的架构设计方案,是使用数据冗余这种反范式设计来满足分库后不同维度的查询需求。 ...
阅读(44) 评论(0)

MySQL双主一致性架构优化

一、双主保证高可用 MySQL数据库集群常使用一主多从,主从同步,读写分离的方式来扩充数据库的读性能,保证读库的高可用,但此时写库仍然是单点。   在一个MySQL数据库集群中可以设置两个主库,并设置双向同步,以冗余写库的方式来保证写库的高可用。   二、并发引发不一致 数据冗余会引发数据的一致性问题,因为数据的同步有一个时间差,并发的写入可能导致数据同步失败,...
阅读(36) 评论(0)

或许你不知道的10条SQL技巧

这几天在写索引,想到一些有意思的TIPS,希望大家有收获。   一、一些常见的SQL实践 (1)负向条件查询不能使用索引 select * from order where status!=0 and stauts!=1 not in/not exists都不是好习惯 可以优化为in查询: select * from o...
阅读(20) 评论(0)

分层架构,是否需要业务服务层

《互联网分层架构的本质》简述了两个观点: 互联网分层架构的本质,是数据的移动 互联网分层架构演进的核心原则:是让上游更高效的获取与处理数据,让下游能屏蔽数据的获取细节   《分层架构:什么时候抽象DAO层,什么时候抽象数据服务层》中的观点是: 当手写代码从DB中获取数据,成为通用痛点的时候,就应该抽象出DAO层,简化数据获取过程,提高数据获取效...
阅读(27) 评论(0)

互联网分层架构之-DAO与服务化

互联网分层架构的本质,是数据的移动。   互联网分层架构演进的核心原则: 让上游更高效的获取与处理数据,复用 让下游能屏蔽数据的获取细节,封装   这些在上一篇《互联网分层架构的本质》中有详尽的描述,在实际系统架构演进过程中,如何利用这两个原则,对系统逐步进行分层抽象呢?咱们先从后端系统开始讲解。...
阅读(84) 评论(0)
102条 共7页首页 上一页 1 2 3 4 5 ... 下一页 尾页
    个人资料
    • 访问:18279次
    • 积分:1077
    • 等级:
    • 排名:千里之外
    • 原创:92篇
    • 转载:10篇
    • 译文:0篇
    • 评论:5条
    文章分类
    最新评论