关于项目中redis实例和mq的实例

redis和mq的问题;
1：回头问一下为什么用数据库分布式锁而不用redis的分布式锁呢？

2:项目中用到的redis：
主要就是在处理业务检测的心跳的时候把心跳信息存到redis中使用。是一个热点数据的查询。然后就是自己封装了redsi的工具类，主要是对get,set,String,Integer,Long数据类型的方法封装。以及封装了分布式锁的获取，释放，还有自增方法以及超时方法的封装。
这些封装统一都是用try，catch包着，然后finally关闭jedis来用的。
3：redis写的分布式锁：
两种方式：
一：
二：
4：高频号码被叫次数统计任务写法：
场景：
客服部门每天会在client页面进行外呼，大概每天会呼叫几万次不同的号码，平均每分钟也有几百个，本来的数据是存放在db中的，现在根据防骚扰政策，一天内对一个号码呼叫次数超过三次，则被定性为骚扰电话，所以我们需要在客服点击电话外呼的时候去查询一次db库里保存着今天打了几次电话，然后没超过三次外呼，并且次数加一，超过弹框提示。第二天o时统一次数清零。由于每个人每天会被分配到不同的号码，所以不会存在高并发的写操作。但是频繁的连接db，关闭db会造成系统卡顿甚至系统崩溃。
改进方案：
把数据放在redis中，然后保留一天时间段的数据里面的次数，设置失效时间，查询的时候直接从redis中去查就好了。

贷后项目KAFKA的用法：
已经放款下单的汽车分期案件的生产者在哪。
我们猎风者放款下单是下到哪里了
档案系统中的MQ消费者：
1：在xml里面配置消费者，把消费方法通过bean注入到spring容器中，然后通过bean注入消费者实例，通过property以及map标签把消费分组LoanPostManageService我们用项目名来分组的，客户端id，服务端地址是否启用消费者和订阅关系放到map中。
2：然后消费者被触发后进入到前面bean注入的方法中进行消费。该方法会先继承一个基础消费的类，然后加上一个mqlog的注解，自定义的一个注解，主要是锁定关键信息，便于排障和监控。
3：写一个抽象的基础消费者类。
基础消费者是对请求的报文做一个反序列化的转换，因为kafka的生产者生产消息到kafka的报文格式是String，我们需要把这些格式反序列化为我们需要的类型参数。
用的方法是：利用我们封装的一个stringToClassOfT的方法，利用ParameterizedType
参数类型的getActualTypeArguments[0]获取一个具体的类型，也就是content需要反序列化的类型。传入到该封装方法中。得到一个序列化的mqrequest请求。
封装方法中使用的是gsonBuilder.create().fromJson方法来把json报文转换为实体类的。
经过上面的操作后，就拿到了正常实体类型的消息请求了
4：当我们在消费方法中通过基础消费获得实体后，然后把实体请求中的请求类型和流水作为服务来源和sessionid传入到请求报文实体，去做通知进件的请求，调用业务方法。
5：我的业务功能：
就是通过渠道端生产消息我们消费，获得消费请求，请求里面有需要的字段比如名字，卡部，服务端，订单类型等等，我们排除车位分期的业务类型，并且根据案件编号进行查询实体防止重复通知，完了之后就进行实体绑定赋值，执行落库操作，设置当前状态为已放款下单。

关于kafka的工作原理：
1：消息推送模式：有两种模式：
一是点对点的模式，该模式的特点是当生产者发布消息到队列中后，只有一个消费者可以消费。它的优点是消费者自己控制拉取消息的频率，缺点是无法感知队列中是否有新消息。
而是发布订阅模式，该模式是生产者把消息放到队列后，就不管了，队列根据消费者订阅的消息进行推送。这样消费者是有感知的，但是不能自己控制发送速度，所以当多个消费者订阅同一个消息的时候，可能会因为服务器性能不一致导致接受消息的速度有差异。
2：猎风者审核通过后工作流会流转到渠道端，然后渠道端去作为生产者生产消息，然后发布到kafka集群上，再然后是贷后系统去订阅kafka上面的消息作为消费者来消费已放款下单的案件。
3：定时任务和消息队列：定时任务和消息队列都可以实现解耦，但是定时任务趋于解决批量处理，比如自动派件，逐个派件，预处理打标。 消息呢也很多，放款下单，照会资信。
一般对于跨系统间的队列我们用的是消息，这样实现完全解耦，无须关心上层的变化。
4：kafka的相关概念：
Producer：Producer即生产者，消息的产生者，是消息的入口。
　　kafka cluster：
　　　　Broker：Broker是kafka实例，每个服务器上有一个或多个kafka的实例，我们姑且认为每个broker对应一台服务器。每个kafka集群内的broker都有一个不重复的编号
　　　　Topic：消息的主题，可以理解为消息的分类，kafka的数据就保存在topic。在每个broker上都可以创建多个topic。我们的topic是订单消费
　　　　Partition：Topic的分区，每个topic可以有多个分区，分区的作用是做负载，提高kafka的吞吐量。同一个topic在不同的分区的数据是不重复的，partition的表现形式就是一个一个的文件夹！我们的Partition是档案贷后项目名
　　　　Replication:每一个分区都有多个副本，副本的作用是做备胎。当主分区（Leader）故障的时候会选择一个备胎（Follower）上位，成为Leader。在kafka中默认副本的最大数量是10个，且副本的数量不能大于Broker的数量，follower和leader绝对是在不同的机器，同一机器对同一个分区也只可能存放一个副本（包括自己）。
　　　　Message：每一条发送的消息主体。
　　Consumer：消费者，即消息的消费方，是消息的出口。
　　Consumer Group：我们可以将多个消费组组成一个消费者组，在kafka的设计中同一个分区的数据只能被消费者组中的某一个消费者消费。同一个消费者组的消费者可以消费同一个topic的不同分区的数据，这也是为了提高kafka的吞吐量！
　　Zookeeper：kafka集群依赖zookeeper来保存集群的的元信息，来保证系统的可用性。
工作流程：

值得注意的是:生产者通过push模型把消息分发到kafka集群中的不同分区中顺序写入磁盘中，所以她的消息是有序的，然后follower是主动去leader处获取数据的。
5：

总结：
1：zk集群，树形结构做配置中心。
2：redis做分布式锁处理。3：Kafka做消费者消费信息。4：数据库分布式锁处理定时任务。批量审批，同时更新两张表用事务。做日志处理用aop落库。做利星行二手车做查询优化索引。做审批前处理做db连接优化。做loan的时候碰到了堆内存溢出。做代后的时候用到了nginx做跨越处理。平常是bean注入。平常是ioc控制反转。
多线程是自定义了线程池来操作线程，比如日志异步处理，涉及到单例模式。工厂模式的使用方法是什么。Acs上云用到了通讯协议。Io流未知。表格导出的写法。React,anglarjs，vincio决策平台，activity工作流的用法。另外再加上boot和cloud的用法以及基础算法。

三：Zk搭建配置中心的方式：
我们使用的zk客户端框架是curator，