红包小程序

最近做一个口令红包的微信小程序，说对口令就可以领红包。项目今天正式完工之后，收益甚大，在这里做个回顾和反思。反思再做项目过程中遇到的问题，总结在项目中学到的新的知识，只有这样才能不断的提高自己的专业技能和编程水平。

首先是语音解析方面，调用的是百度官方的语音解析功能。将语音转换成文字，最开始做的时候没考虑那么多直接拿转换成的语音文字与事先发红包时的口令进行比较，后来发现简单的语音解析是可以解析出正确的答案，随着发布口令的复杂或者发布的口令有多音字的功能（这里不得不佩服中华汉字的博大精深）解析出来的汉字就不是我们所需要的汉字，每句话百度语音解析出来的汉字是个json的数组。而百度语音解析功能本身也不是非常的准确，为了解决这一问题就将百度语音解析出的汉字转换成拼音，数据库中存放的口令也转换成拼音，将转换成的汉语拼音和数据库中存放的口令转成的拼音进行匹配当匹配率打到百分之七十的时候就可以认定这个口令是正确，就可以领到这个红包。

调用百度语音解析功能也需要获取access_token在这个项目中因为有生成小程序二维码而二维码也需要微信的access_token，因此就把微信的access_token和百度语音的access_token放在了一起写了个定时任务每隔多少秒去执行以下这个定时任务分别获取到所需要的accesss_token。

这个项目中最主要的还是高并发的问题。因为同一时间可能有很多人使用这个小程序进行领红包，因此必须保证每个红包每个人在同一时间只能领到一个。在这里采取了时间锁，每个人进来之后用当前的时间戳给这个红包加锁，这个时间戳是精确到毫秒级的，将红包的状态变为9，然后给当前用户分配红包，分配完红包之后修改红包的状态为1领取成功，如果修改的数据超过一条则认为这个红包领取失败。领取红包失败后事务回滚，所有的红包都变成最原始的状态。

发完红包，分配红包的时候有两种分配规则，一种是发完红包就将红包拆分好存到数据库中，每来一个用户要领的时候就给他分配一个红包。还有一种方式是在领取过程中边领边拆红包。我采用的是第一种方式发完红包之后就将红包拆分然后存到数据库中。

在这个项目中最大的收获就是高并发事务的处理，在此之前做的项目中用到高并发的地方并不多甚至对高并发事务完全不了解。通过这个项目虽然不能说是精通高并发事务的处理，但是至少弥补了自己在这方面知识的欠缺。自己也上网查了高并发事务的处理，目前就常见的就是乐观锁和悲观锁的两种处理方式。

乐观锁机制是在数据库中加一字段为版本号，每次请求过来时查出该版本号，处理完所需的业务逻辑之后将该版本号加1，加1后的版本号和数据库中存储的版本号进行比较如果大于数据库中存储的版本号则将加1后的版本号更新至数据库中，如果等于当前版本号则请求作废。这样就可以保证多个请求过来时，保证每一个请求的正确性。

悲观锁机制： 悲观锁，正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自 外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。 悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能 真正保证数据访问的排他性，否则，即使在本系统 中实现了加锁机制，也无法保证外部系 统不会修改数据）。 

一个典型的倚赖数据库的悲观锁调用： 

 select * from account where name=”Erica” for update

这条 sql 语句锁定了 account 表中所有符合检索条件（ name=”Erica” ）的记录。

本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。

这些经验将为我下一步的工作打下坚实的基础。仍需继续努力