一、业务 特点 ：海量的并发要求；严格的安全级别
二、技术 难点 ：并发请求抢锁；事务级 *** 作量级大；事务性要求严格
三、解决高并发问题 通常 使用的 方案 ：
1.使用内存 *** 作替代实时的DB事务 *** 作（优点：内存 *** 作替代磁盘 *** 作，提高了并发性能。）
2使用乐观锁替代悲观锁。应用于微信红包系统，则会存在下面三个问题：滚并返回失败；并发大失败，小成功。DB压力大。
四、微信 红包 系统的高并发解决 方案 ：
1.系统垂直SET化，分而治之。
2.逻辑Server层将请求排队，解决DB并发问题。
3.双维度库表设计，保障系统性能稳定
类似“秒杀”活动，群里发一个红包=“秒杀”商品上架；抢红包的动作=“秒杀”的查询库存；拆红包=“秒杀”
同一时间有10万个群里的用户同时在发红包，那就相当于同一时间有10万个“秒杀”活动发布出去。10万个微信群里的用户同时抢红包，将产生海量的并发请求。
微信红包是微信支付的一个商户，提供资金流转服务。
用户发红包=购买一笔“钱”（在微信红包这个商户上），并且收货地址是微信群。当用户支付成功后，红包“发货”到微信群里，群里的用户拆开红包后，微信红包提供了将“钱”转入折红包用户微信零钱的服务。
资金交易业务比普通商品“秒杀”活动有更高的安全级别要求。普通的商品“秒杀”商品由商户提供，库存是商户预设的，“秒杀”时可以允许存在“超卖”、“少卖”的情况。但是对于微信红包，100元不可以被拆出101元；领取99元时，剩下的1元在24小时过期后要精确地退还给发红包用户，不能多也不能少。
在介绍微信红包系统的技术难点之前，先介绍下简单的、典型的商品“秒杀”系统的架构设计，如下图所示。
该系统由接入层、逻辑服务层、存储层与缓存构成。Proxy处理请求接入，Server承载主要的业务逻辑，Cache用于缓存库存数量、DB则用于数据持久化。
一个“秒杀”活动，对应DB中的一条库存记录。当用户进行商品“秒杀”时，系统的主要逻辑在于DB中库存的 *** 作上。一般来说，对DB的 *** 作流程有以下三步：
a. 锁库存
b. 插入“秒杀”记录
c. 更新库存
a.锁库存是为了 避免 并发请求时出现“ 超卖 ”情况。同时要求这 三步 *** 作 需要在 一个事务 中完成(难点:并发请求抢锁)。
第一个事务完成提交之前这个锁一直被第一个请求占用，后面的所有请求需要 排队等待 。同时参与“秒杀”的用户越多，并发进DB的请求越多，请求 排队越严重 。
红包系统的设计上， 除了并发请求抢锁之外，还有以下两个突出难点 ：
首先，事务级 *** 作量级大 。上文介绍微信红包业务特点时提到，普遍情况下同时会有数以万计的微信群在发红包。这个业务特点映射到微信红包系统设计上，就是有数以万计的“并发请求抢锁”同时在进行。这使 得DB的压力 比普通单个商品“库存”被锁要大很多倍。
其次，事务性要求严格 。微信红包系统本质上是一个资金交易系统，相比普通商品“秒杀”系统有更高的事务级别要求。
普通商品“秒杀”活动系统，解决高并发问题的方案，大体有以下几种：
如图2所示，将“实时扣库存”的行为上移到 内存Cache中 *** 作 ，内存Cache *** 作成功直接给Server返回成功，然后 异步落DB持久化 。
优点：提高了并发性能。
缺点： 在内存 *** 作 成功 但 DB持久化失败 ，或者内存 Cache故障 的情况下，DB持久化会 丢数据 ，不适合微信红包这种资金交易系统。
商品“秒杀”系统中，乐观锁的具体应用方法，是在DB的“库存”记录中维护一个版本号。在更新“库存”的 *** 作进行前，先去DB获取当前版本号。在更新库存的事务提交时，检查该版本号是否已被其他事务修改。如果版本没被修改，则提交事务，且版本号加1；如果版本号已经被其他事务修改，则回滚事务，并给上层报错。
这个方案解决了“并发请求抢锁”的问题，可以提高DB的并发处理能力。
应用于微信红包系统，则会存在下面三个问题 ：
1.在并发抢到相同版本号的拆红包请求中， 只有一个能拆红包成功 ， 其他的请求 将事务回滚并返回失败，给用户 报错 ，用户体验完全不可接受。
2.将会导致 第一时间 同时拆红包的用户有一部分直接 返回失败 ，反而那些“ 手慢 ”的用户，有可能因为 并发减小 后拆红包 成功 ，这会带来用户体验上的负面影响。
3.会带来 大数量 的 无效 更新 请求 、事务 回滚 ，给 DB 造成不必要的额外 压力 。
微信红包用户发一个红包时，微信红包系统生成一个ID作为这个红包的唯一标识。接下来这个红包的所有发红包、抢红包、拆红包、查询红包详情等 *** 作，都根据这个ID关联。
红包系统根据这个红包ID，按一定的规则（如按ID尾号取模等），垂直上下切分。切分后，一个垂直链条上的逻辑Server服务器、DB统称为一个SET。
各个SET之间相互独立，互相解耦。并且同一个红包ID的所有请求，包括发红包、抢红包、拆红包、查详情详情等，垂直stick到同一个SET内处理，高度内聚。通过这样的方式，系统将所有红包请求这个巨大的洪流分散为多股小流，互不影响，分而治之，如下图所示。
这个方案解决了同时存在海量事务级 *** 作的问题，将海量化为小量。
红包系统是资金交易系统，DB *** 作的事务性无法避免，所以会存在“并发抢锁”问题。但是如果到达DB的事务 *** 作（也即拆红包行为）不是并发的，而是串行的，就不会存在“并发抢锁”的问题了。
按这个思路，为了使拆红包的事务 *** 作串行地进入DB，只需要将请求在 Server层以FIFO （ 先进先出 ）的方式排队，就可以达到这个效果。从而问题就集中到Server的FIFO队列设计上。
微信红包系统设计了分布式的、轻巧的、灵活的FIFO队列方案。其具体实现如下：
首先，将同一个红包ID的所有请求stick到同一台Server。
上面SET化方案已经介绍，同个红包ID的所有请求，按红包ID stick到同个SET中。不过在同个SET中，会存在多台Server服务器同时连接同一台DB（基于容灾、性能考虑，需要多台Server互备、均衡压力）。
为了使同一个红包ID的所有请求，stick到同一台Server服务器上，在SET化的设计之外，微信红包系统添加了一层基于红包ID hash值的分流，如下图所示。
其次，设计单机请求排队方案。
将stick到同一台Server上的所有请求在被接收进程接收后，按红包ID进行排队。然后 串行地进入worker进程 （执行业务逻辑）进行处理，从而达到 排队 的效果，如下图所示。
最后，增加memcached控制并发。
为了 防止 Server中的请求队列过载导致队列被降级，从而所有请求 拥进DB ，系统增加了与Server服务器同机部署的 memcached ，用于控制拆同一个红包的 请求并发数 。
具体来说，利用memcached的 CAS原子累增 *** 作 ，控制同时进入 DB执行拆红包事务的请求数 ，超过预先设定数值则 直接拒绝服务 。用于 DB负载升高时的降级 体验。
通过以上三个措施，系统有效地 控制了DB的“并发抢锁” 情况。
红包系统的分库表规则，初期是根据 红包ID的hash值 分为多库多表。随着红包数据量逐渐增大，单表数据量也逐渐增加。而DB的性能与单表数据量有一定相关性。当单表数据量达到一定程度时，DB性能会有大幅度下降，影响系统性能稳定性。采用 冷热分离 ，将历史冷数据与当前热数据分开存储，可以解决这个问题。
系统在以 红包ID维度 分库表的基础上，增加了以 循环天分表的维度 ，形成了 双维度分库表 的特色。
具体来说，就是分库表规则像db_xx.t_y_dd设计，其中，xx/y是红包ID的 hash值后三位 ，dd的取值范围在01~31，代表一个月天数最多 31 天。
通过这种双维度分库表方式，解决了DB单表数据量膨胀导致性能下降的问题，保障了系统性能的稳定性。同时，在热冷分离的问题上，又使得数据搬迁变得简单而优雅。
综上所述，微信红包系统在解决高并发问题上的设计，主要采用了SET化分治、请求排队、双维度分库表等方案，使得单组DB的并发性能 提升了8倍 左右，取得了很好的效果。
http://www.infoq.com/cn/articles/2017hongbao-weixin
在数据库中增加一条红包记录，存储到CKV，设置过期时间；在Cache（可能是腾讯内部kv数据库，基于内存，有落地，有内核态网络处理模块，以内核模块形式提供服务））中增加一条记录，存储抢红包的人数N抢红包后台 *** 作：
抢红包分为抢和拆，抢 *** 作在Cache层完成，通过原子减 *** 作进行红包数递减，到0就说明抢光了，最终实际进入后台拆 *** 作的量不大，通过 *** 作的分离将无效请求直接挡在Cache层外面。这里的原子减 *** 作并不是真正意义上的原子减 *** 作，是其Cache层提供的CAS，通过比较版本号不断尝试，存在一定程度上的冲突，冲突的用户会放行，让其进入下一步拆的 *** 作，这也解释了为啥有用户抢到了拆开发现领完了的情况。
拆红包在数据库完成，通过数据库的事务 *** 作累加已经领取的个数和金额，插入一条领取流水，入账为异步 *** 作，这也解释了为啥在春节期间红包领取后在余额中看不到。拆的时候会实时计算金额，其金额为1分到剩余平均值2倍之间随机数，一个总金额为M元的红包，最大的红包为 M * 2 /N（且不会超过M），当拆了红包后会更新剩余金额和个数。财付通按20万笔每秒入账准备，实际只到8万每秒。
提到抢红包，就不得不提Xposed框架，它简直是个抢红包的神器，但使用Xposed框架有一个前提条件：手机需要root，对于苹果手机的话就需要越狱了。现在的手机想要root或越狱并不容易，同时这会对手机安全性带来一些风险，抢红包本身只是个 娱乐 活动，这样做就得不偿失了。
为了自动抢红包，python能帮我们实现吗？
答案是肯定的，本文就带大家一起 探索 下用Python如何实现自动抢红包。
*** 作系统：Windows
Python版本：3.7.2
手机系统：Android
这里我们的需求是实现自动抢红包。首先要打开微信，进入到指定的群聊，识别微信红包、执行抢红包的动作。这就是关键的步骤，简单清晰。
因为电脑版本的微信没有抢红包的功能，我们只能手机微信，那么就需要把手机连上电脑，通过电脑控制手机来自动抢，那就需要确保「 adb 」命令可正常执行。
识别微信中的消息，是红包还是普通的信息，这里我们通过聊天消息的元素标识来判断。这里我们借助了「 Airtest IDE 」工具来实现。
要正常使用「adb」需要打开USB调试，设置项通常出现在手机系统设置中的[开发人员选项]里面。
在手机上打开USB调试后，接下来我们通过Airttest IDE验证 adb 运行是否正常。
开始之前先，先解释下airttest相关概念：
Airtest IDE 的下载地址：
下载之后，解压打开就可以使用，Airtest IDE的界面如下：
使用AirtestIDE对Android应用进行自动化 *** 作，第一步就需要连接Android设备。
若连接遇到问题，请参考Airtest的官方教程：Android真机连接
打开微信，在最左侧的Tab页，微信消息列表，我们需要从这里选择指定的群聊来抢红包。
在AirtestIDE中，我们可以通过暂停功能，冻结当前的UI树形结构来精确地检视UI控件，我们先来分析下这个页面中元素标识。
聊天页面中整体的群聊消息的元素标识 com.tencent.mm:id/d1v
聊天页面中单个群聊消息的元素标识 com.tencent.mm:id/b6e
接下来进入我们准备要抢红包的群聊中，识别出红包并执行抢红包的动作。
我们先来看看红包的标识：
红包标识的示例1 com.tencent.mm:id/aql
红包标识的示例2 com.tencent.mm:id/aql
点击红包，记录下d出的大红包页面中“开”的元素标识
大红包页面中”开“的标识 com.tencent.mm:id/d02
这里我们需要判断是红包是否有效，比如已被领完或是已被自己领取的红包就是无效的，我们在执行时可以跳过这些。
已领取红包的标识 com.tencent.mm:id/apk
已被领完红包的标识 com.tencent.mm:id/apk
我们用的各元素的标识都已取到，接下来就是组织我们的代码。
首先得打开微信，利用Airtest启动app应用，只须一行代码即可搞定，如下
获取当前页面中所有所有群聊的名称
选择并进入指定的群聊
遍历消息并查找红包
在LuckyMoney中定义抢红包的动作
若我们在一台电脑上并不想安装Airtest IDE，还能执行这个脚本吗？
当然可以，只需要安装好「 pocoui 」这个第三方库就可以“抛弃”它了！
利用 AirtestIDE 创建一个项目时，设备类型选中 Android，就会在编码区生成一段初始化的代码。
我们自己编写的Python代码中也需要加上这段初始化的代码。
再次强调，在执行脚本时要确保手机连上电脑，并确保「adb」命令正常运行。
对Airtest有兴趣的小伙伴，可以参考airtest官方教程：AirtestIDE官方文档
评论区评论： python抢红包 ，获取本文所涉及的完整代码
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）