m0_73856804的博客

我们按照月来统计用户签到信息，签到记录为1，未签到记录为0，这样我们只需要最多31bit就可以表示一个用户一个月的签到情况，非常节省空间，这种做法的核心思想就是把每一个比特位对应当月的每一天，形成了映射关系，用0和1表示业务状态。在请求解析中，我们发现请求参数与返回值都为空，这是因为我们签到所需的用户以及当天日期都可以在后端直接获取，因此不需要前端传参，也不需要返回值，但如果是补签功能的话，就需要前端传递日期参数了。方法2：从最后一个比特位开始遍历，并定义一个计数器，为1则加一，为0则终止。

在微信中有附近的人的功能，在外卖软件中就会有附近商户的功能，打车软件中会有附近的车的功能等等，这些功能的底层都是基于地理坐标进行搜索，支持地理坐标的技术很多，redis就是其中之一，在这里主要学习基于Redis实现地理坐标的搜索功能。实现思路：前端发送请求，请求中的typeID到数据库中过滤，找到对应的店铺，做分页返回前端，而将商户id与经纬度使用GEO数据结构存入redis中，将来在收到请求时就按照经纬度来筛选，得到商户id，在拿id来数据库查询商户具体信息。

已有的注解不能满足所有的校验需求，特殊的情况需要自定义校验，（自定义校验注解）实现步骤自定义注解state自定义校验数据的State Validation实现ConstraintValidator接口在需要校验的地方使用自定义注解代码展示：@State​​​//在属性上生效//在运行时阶段保留// 自定义注解 提供校验规则//提供校验失败后的提示信息String message() default "文章状态只能是：已发布或者草稿";//指定分组。

举例说明：为每个博主准备一个发件箱，发送消息到邮箱，消息需要带上时间戳，timeline的核心是按时间排序，因此需要带上时间戳，其他人在发消息时，时间戳就会递增，而为粉丝准备一个收件箱，收件箱平时是空的，只有粉丝要去读消息的时候，才会给他拉取，首先先查看粉丝关注的博主，就将其关注的所有人的发件箱的消息拉到他的收件箱里，再做时间上的排序。想要做到共同关注，就需要在关注接口上，将当前用户关注的用户id保存到Redis的set数据结构中，目标用户关注的用户id也需要将其保存到redis中。

需要注意的是发布照片与发布笔记是两个分离的功能，因为上传照片的功能不仅仅是发笔记有这个需求，在其他业务中可能也会需要发布照片，因此上传照片功能是一个独立功能，点击上传照片时会先发出一个请求实现上传，上传成功后返回这张图片的地址，也就是上传之后的可访问的地址，这个地址就会做为表单的参数，在发布笔记时一起提交到后台，即在发布笔记时上传的其实不是照片的本身，而是上传成功后的图片地址，因此发布照片和发布笔记是不同的功能，会发起两个不同的请求。

在进行下一次读取，继续循环，如果在处理消息的过程抛出异常，导致该消息没有确认，那么该消息就会进入pending-list，就被catch到，在catch中执行handlePendinglist（）函数，在该函数中，首先去pending-list获取未确认消息，如果读到，则解析消息，处理，下单，ack确认，如果没有异常消息，就会直接跳出循环，异常处理结束，如果再抛异常，就再度循环。项目启动后，开启一个线程任务，尝试获取stream.orders中的消息，完成下单。至此优化秒杀下单的业务需求完成。

因此如果要在redis的三种消息队列中选择的话，肯定是用stream模式，但是如果业务较为庞大，对于消息队列的要求更加严格，还是选要使用更加专业的消息队列比如RabbitMQ等，因为stream虽然支持消息的持久化，但这种持久化是依赖于Redis本身持久化的，Redis的持久化也可能会出现问题，而且消息确认机制只支持消费者的确认机制，不支持生产者确认机制，另外消息的事务机制，再多消费者下的消息有序性等等，还是有很多问题的，还是需要更加强大的消息队列去支持，但如果对消息队列要求不高，还是可以使用的。

我们为了解决优惠卷秒杀的问题添加了各种锁，这就会导致秒杀业务的性能降低，因此需要去优化秒杀业务，进一步提高性能。首先回顾一下业务流程：前端发起请求到达Nginx服务器，Nginx会将请求负载均衡到Tomcat，在通Tomat内部，首先会查询优惠券个数，去做库存的判断，如果库存没有问题就去查询订单，校验一人一单，如果还没有问题，就去扣减库存，创建订单。

redisson分布式锁原理：可重入：利用hash结构记录线程id和重入次数，当线程获取锁失败后去判断锁包含的线程id是否一致，如果一致，则让其获取锁，并且重入次数加一。在释放锁时，先去判断锁中的线程ID，再去判断重入次数是否为0，如果为0，则释放，不为0，则无视可重试：利用信号量和pubsub功能实现等待、唤醒、获取锁失败的重试机制。在第一次获取锁失败以后，并不是直接返回false，尝试获取锁的返回结果就是ttl（剩余有效时间），如果返回值为null。则获取锁成功，若不为null，则获取锁失败，

写出完整的过程，说明信号量的含义并赋初值。作者与任意进程都是互斥的，读者与读者同步，和作者互斥，因此需要设置计数器，用他来判断当前是否有读者读文件，当有读者读文件时，作者无法写文件，读者一直占用文件，当没有毒这时，作者才可以写文件，同时，读者对计数器的访问也应该是互斥的。当没有进程在临界区时，任意一个进程要进入临界区，就要执行P操作，把S的值减为0，然后进入临界区，当有进程进入临界区时，S的值为0，再有进程要进入临界区，执行P操作就会阻塞，直至在临界区的进程退出，这样就实现了临界区的互斥。

进程是程序一次执行的过程。进程是具有独立功能的程序在一个数据集合上运行的过程，他是系统进行资源分配和调度的一个独立单位引入进程后，进程是资源分配的独立单位，进程具有并发性，可以和其他进程并发执行同一个程序执行在不同的数据集合上，属于不同的进程进程是进程实体的运行过程，是系统进行资源分配和调度的一个独立单位。

系统运行有三个进程：输入进程、计算进程和打印进程，他们协同完成工作。在第0个时刻，A B C D进程同时到达，对比四个线程之间的运行时间，根据运行时间的长短决定执行顺序，A C 的服务时间是一致的，这时即可以选择调度A，也可以选择调度C，在选择调度 D,进程D执行完后到第10个时刻，进程E已经到达，这时在对比 B,E 进程，根据运行时间执行E，最后执行 B.在一个请求分页系统中，有一个长度为5页的进程，假如系统为他分配3个物理块，并且此进程的页面走向为2,3,2,1,5,2,4,5,3,2,5,2。

在docker客户端输入命令，docker daemon的守护进程会监听该命令，再去对应的镜像仓库去拉去镜像，下载到本地运行，运行时会为镜像区创建一个隔离的环境称之为容器，多个容器之间相互隔离，可以进行多实例部署，形成集群，相互之间没有干扰，也可以在一个服务上去部署多个不同应用的实例，不需要担心相互干扰的问题，搭建集群部署整个复杂的微服务应用非常方便。比如部署MySQL容器，MySQL启动端口为3306，但是容器是隔离环境，有自己独立的内存空间，有自己独立的文件系统，也有自己独立的网络空间。

redisson分布式锁原理：可重入：利用hash结构记录线程id和重入次数，当线程获取锁失败后去判断锁包含的线程id是否一致，如果一致，则让其获取锁，并且重入次数加一。在释放锁时，先去判断锁中的线程ID，再去判断重入次数是否为0，如果为0，则释放，不为0，则无视可重试：利用信号量和pubsub功能实现等待、唤醒、获取锁失败的重试机制。在第一次获取锁失败以后，并不是直接返回false，尝试获取锁的返回结果就是ttl（剩余有效时间），如果返回值为null。则获取锁成功，若不为null，则获取锁失败，

同一个线程无法获取同一把锁可重入就是指同一个线程可以多次获取同一把锁。举例说明：方法a调用方法b，在方法a重要先获取锁，然后执行业务，去调用方法b，然后方法b也需要获取同一把锁，在这种情况下，如果锁是不可重入的，方法a中获取锁之后，方法b就无法获取锁，只能等待方法a中锁的释放，但锁无法释放，因为方法a的业务没有完成，于是就会出现死锁的情况。在这种场景下，我们要求的锁是可重入锁。：获取锁只尝试一次就返回false，没有重试机制。

假设有两个JVM，JVM1中的线程A，来获取锁，就需要去寻找外部的锁监视器，一旦获取成功，就回去记录当前获取锁的是这个线程A，在高并发情况下，此时如果有其他线程也来获取锁，比如JVM2线程中的线程C，但因为外部的锁监视器中已经记录锁的持有者了，因此线程C获取锁失败，则需要等待锁释放，当线程A释放锁成功后，线程C来获取锁，之后执行自己的业务。线程开启，尝试获取锁，执行命令，结果有两种，OK,NIL，NIL代表失败，证明锁已经被获取，OK代表获取互斥锁成功，则执行业务，业务执行完之后，释放锁。

而现在是在方法内部加的锁，就有一个问题：比如方法开启事务，开始执行，获得锁之后，开始做查询，查询完之后减库存，提交订单，然后需要先释放锁，才能提交事务，因为事务被spring容器管理，所以事物的提交是在我们函数执行完以后，由spring做的提交，而在高并发情况下，在锁释放时，可能就已经有线程进行访问了，而此时由于事务尚未提交，如果有别的线程来查询订单，那我们刚新增的订单可能还没有写入数据库，因为没有提交事务，就有可能出现并发安全问题。这样一来，只要拿到的用户ID值一样，那么返回的结果永远一样。

假如现在只剩下一个商品，但在高并发情况下，假如说有两个线程，正常情况下，线程是按顺序执行的，这样两个线程按顺序执行，就不会出现超卖问题，但是在高并发请况下，线程并不按照顺序执行，可能会交叉执行，就会出现两个线程都会读到数据库中的库存还为一，因此两个库存一起扣减库存，于是库存变为了-1，就造成了超卖问题,，其实就是多线程并发安全问题。例如，线程A先去查询库存，在进行判断，最后在进行扣减时，在进行一次对库存的判断，要求查询到的库存需要和开始查询到的库存保持一致即可。不满足则回滚，其他线程同上。

订单的特点就是数据量比较大，因为用户只要产生购买的行为，就会不停的产生新的订单，如果项目有一定的规模，用户量达到数百万，每天的订单可能就高达数百万，日积月累，单张表显然不能保存如此多的数据，如果无法保存，就需要分到多张表中，如果每张表都采用自增长，每张表都自增，那么订单的id就一定会重复，而订单就不应该重复，因为从业务的角度来考虑，将来一些售后服务还需要订单id，如果id重复，将来一定会出问题。生成时间戳：时间戳是一个31位的数字，单位为秒，需要一个基础的日期作为开始时间，再拿当前时间减去开始时间。

当用户点击左侧的文章分类时，会在页面主区域展示文章分类相关的内容，在页面的右上角有一个添加分类的按钮，点击之后会出现弹窗，用户需要输入分类名称及别名，如果输入校验无错后，最终访问后台接口，完成分类的添加。在文章分类列表中点击编辑按钮，弹出弹窗，在弹窗中需要展示被点击这个分类的详细信息，用户在原有信息的基础上进行修改，要想展示被点击分类的详细信息，就需要去调用获取文章分类详细信息的接口，拿到数据之后展示。把校验项进行归类分组，在完成不同的功能的时候，校验指定组中的校验项。