Onepiecedream的博客

就超人多卖而言，在判断完优惠券库存后，还没来得及更新入库的时候，高并发的情况下，就会出现实际发行的数量高于预定的数量。类似这种更新是导致的数据异常问题，采用乐观锁来解决，可以另外加一个版本字段，更新前判断版本是否改变，改变了就表示被其他线程操作了，本次操作失败或者重试；而单人多卖，判断完领取数量是否小于领取上限后，在向记录用优惠券信息表中插入数据时，导致的多卖问题。事务传播行为有7种，如果某一个事务方法调用了一个必须新事务的事务方法，上来不管是否存在事务，都会创建一个新事务，也会导致外部事务失效。

(采用定时任务，批量添加，主要还是对冲mysql数据库并发能力低，经可能得降低数据库的压力，提高整体的性能)。

比如，在签到中，每次打卡成功后，向MQ投递一个消息，积分微服务作为消息消费者监听MQ，一旦监听到消息，就新增积分。在新增积分的时候，考略到一些业务积分是有上限的，比如学习，提问这些都要设置上限，避免用户无休止的刷积。如果是按照传统的在mysql中建表，虽然可以正常运行，但是每条签到记录都会占用差不多22个字节的空间，常年累月的积累下来，就会造成空间的浪费。首先，真个功能的实现，要借助MQ来实现。单独创建积分微服务，并且让积分微服务作为消息的监听者，其他有几分功能的服务作为消息的发布者，发布消息。

③： 对于Controllerc中的表单提交、前端传的json的数据在方法参数使用@Validated注解，就可以开启校验，如果是单个参数的校验，要注意在Controllerd的类上添加@Validated，参数的约束才会生效。某个问题的所有作答又分为两类，所有直接针对问题的作答为回复或者回答，针对所有回复、回答的作答成为评论，评论并不直接作用于问题，而且回复理论上是可以无限叠楼的。`target_reply_id` ----- '回复的目标回复id',`course_id` --- '所属课程id',

课表添加，涉及到交易和学习两个为微服务，由交易服务，发起远程调用学习服务，完成课程的添加。接下来，就把交易模块看做消息发布者，学习模块看做消息的消费者，以MQ的消息模型作为一个主体开发。课表购买之前只是单纯的课程，平台讲师发布，用户只能看到课程相关的信息。课表查询的具体体现就是，用户购买完课程后，进入学习中心->我的课程，在这一栏就会展示用户购买的所有课程（包含免费课程）。在这儿，根据响应结果可以判断，需要从课程服务中查询课程表的信息。②：获取课程id，根据课程id调用课程微服务，获取课程信息（远程调用）

由于没有端口，使用配置后的域名别名访问的话，默认是发往了80端口，也就是nginx监听的端口，所以，请求会先发送到nginx上，然后通过nginxd的反向代理，将请求服务器上的部署好的某个容器(软件)。本地项目开发完成后(某个具体功能开发完毕)，commit到本地仓库，push到Gogs远程仓库中。接手项目后，管理的能够开发的服务，需要先从Gogs的仓库中，clone到本地。中途接受项目，部分项目服开发完成，需要部署到远程服务器。注意：只会在本机访问有效，因为配置在本机的系统的底层配置中。