扫码登录原理
今天给大家介绍下扫码登录功能是怎么设计的。
扫码登录功能主要分为三个阶段:待扫描、已扫描待确认、已确认。
整体流程图如图。
下面分阶段来看看设计原理。
1、待扫描阶段
首先是待扫描阶段,这个阶段是 PC 端跟服务端的交互过程。
每次用户打开PC端登陆请求,系统返回一个唯一的二维码ID,并将二维码ID的信息绘制成二维码返回给用户。
今天给大家介绍下扫码登录功能是怎么设计的。
扫码登录功能主要分为三个阶段:待扫描、已扫描待确认、已确认。
整体流程图如图。
下面分阶段来看看设计原理。
1、待扫描阶段
首先是待扫描阶段,这个阶段是 PC 端跟服务端的交互过程。
每次用户打开PC端登陆请求,系统返回一个唯一的二维码ID,并将二维码ID的信息绘制成二维码返回给用户。
拼多多有数亿的用户,那么对于某个网页,怎么使用Redis来统计一个网站的用户访问数呢?
1、Hash
哈希是Redis的一种基础数据结构,Redis底层维护的是一个开散列,会把不同的key映射到哈希表上,如果是遇到关键字冲突,那么就会拉出一个链表出来。
当一个用户访问的时候,如果用户登陆过,那么我们就使用用户的id,如果用户没有登陆过,那么我们也能够前端页面随机生成一个key用来标识用户
当用户访问的时候,我们可以使用HSET命令,key可以选择URI与对应的日期进行拼凑,field可以使用用户的id或者随机标识,value可以简单设置为1。
什么是订阅推送?就是用户订阅了优惠劵的推送,在可领取前的一分钟就要把提醒信息推送到用户的app中。具体方案就是到具体的推送时间点了,coupon系统调用消息中心的推送接口,把信息推送出去。
下面我们分析一下这个功能的业务情景。假设公司目前注册用户6000W+,比如有一张无门槛的优惠劵下单立减20元,那么抢这张劵的人就会比较多,我们保守估计10W+,百万级别不好说。我们初定为20W万人,那么这20W条推送信息要在一分钟推送完成!并且一个用户是可以订阅多张劵的。所以我们知道了这个订阅功能的有两个突出的难点:
1、推送的实效性:推送慢了,用户会抱怨没有及时通知他们错过了开抢时机。
今天和大家聊聊权限系统设计常见的方案。
日常工作中权限的问题时时刻刻伴随着我们,程序员新入职一家公司需要找人开通各种权限,比如网络连接的权限、编码下载提交的权限、监控平台登录的权限、运营平台查数据的权限等等。
在很多时候我们会觉得这么多繁杂的申请给工作带来不便,并且如果突然想要查一些数据,发现没有申请过权限,需要再走审批流程,时间拉得会很长。那为什么还需要这么严格的权限管理呢?
举个例子,一家支付公司有运营后台,运营后台可以查到所有的商户信息,法人代表信息,交易信息以及费率配置信息,如果我们把这些信息不加筛选都给到公司的每一个小伙伴,那么跑市场的都可以操作商家的费率信息,如果一个不小心把费率改了会造成巨大的损失。
本篇分享如何设计一个抢红包系统,希望对大家有所帮助。主要展示抢红包系统的设计,红包算法不是重点,所以没有二倍均值法之类的实现。
常见的红包系统,由用户指定金额、红包总数来完成红包的创建,然后通过某个入口将红包下发至目标用户,用户看到红包后,点击红包,随机获取红包,最后,用户可以查看自己抢到的红包。整个业务流程不复杂,难点在于抢红包这个行为可能有很高的并发。所以,系统设计的优化点主要关注在抢红包这个行为上。
由于查看红包过于简单,所以本文不讨论。那么系统用例就只剩下发、抢
两种。
如果让你来设计一个 MQ,该如何下手?需要考虑哪些问题?又有哪些技术挑战?
对于 MQ 来说,不管是 RocketMQ、Kafka 还是其他消息队列,**它们的本质都是:一发一存一消费。**下面我们以这个本质作为根,一起由浅入深地聊聊 MQ。
将 MQ 掰开了揉碎了来看,都是「一发一存一消费」,再直白点就是一个「转发器」。
生产者先将消息投递一个叫做「队列」的容器中,然后再从这个容器中取出消息,最后再转发给消费者,仅此而已。
在用户选购商品时,下单前,暂存用户想购买的商品。
购物车对数据可靠性要求不高,性能也无特别要求,在整个电商系统是相对容易设计和实现的一个子系统。
购物车系统的主要功能:
支撑这些功能,存储模型如何设计?
只要一个“购物车”实体。
今天,给大家分享如何设计一个注册中心。
不管是出于面试,还是深入学习注册中心,关于如何设计一个注册中心都是一个很好的话题。
假设现在我们系统有两个小系统:
单个系统分别部署在不同服务器上,如果我们订单系统需要调用商品系统的某个服务:
方法1:商品系统开发的朋友告诉你对应的地址。
在高并发的情景下进行系统设计,
可以分为以下 6 点:
将一个系统拆分为多个子系统,用 RPC 来搞。然后每个系统连一个数据库,这样本来就一个库,现在多个数据库,分担系统压力。