纯技术日报的一个话题。

纯技术每日一题

一、11/4 （token、过期、分布式、多个节点多次调用）

业务背景

孟的同学在做压力测试，发现了一个小问题，因为他们在终端设备上和鹅厂有着密切的合作，在调用他们的接口时需要获取access_token，但是这个access_token的到期时间是2个小时，到期后需要重新获取。

在压力测试过程中，发现当到达到期时间时，在日志中发现了几个不同的access_token，因为这个服务也是分布式的，很多节点同时发起了第三方接口请求。

虽然以上次获得的access_token为准，没有不利的副作用，但是会导致很多不必要的调用第三方接口，也会造成access_token在短时间内反复无效获取。

讨论

只能有一个调用三向接口获取的线程调用三向接口获取，然后放入缓存。其他线程总是从缓存中获取它。

这种感觉应该用分布式锁来处理。默认情况下，它是从缓存中获取的，缓存不会获取锁。我没明白。等一下。明白了。判断缓存是否存在，如果存在，则直接返回，如果不存在，则重新应用，添加到缓存中，然后释放锁。其他流程也是如此。

嗯哼，冗余access_token出现是因为2小时，请求多。同时判断需要更新access_token，所以确定只有一个请求可以获得access_token，其他的可以等待，然后获得access_token，这样保持一致。这必须是全局锁，加上内部锁，双重锁检查；但是会不会有什么性能问题，这个很难说；

如果您锁定并影响并发，您还不如生成两个。如果第一个失败，使用第二个，然后保存一个备用。两个放进去，一个失败，就取出第二个。

Token加timer，大部分都是分布式方式取token，差不多2小时的时候单线程取token。

使用etcd直接存储令牌，并设置到期时间。如果令牌过期，它会将事件直接推送到etcd，并再次刷新令牌。

这让我想起了网络时代。

不能对所有东西都使用分布式锁的那个对性能来说太差了。

如果是提前生成的，需要在程序中创建一个定时器，这个逻辑不可能穷尽。如果定时器创建失败或程序重启怎么办？仍然存在获得多个令牌问题。

中间件的源代码有问题吗？优先考虑分布式锁。基本上没有这种东西。锁是最后的解决办法。

为什么没人讨论etcd的Watch机制：也就是监控机制，支持Watch的一个固定键和Watch的一个目录(前缀机制)，当Watch的键或目录发生变化时，客户端会收到通知。这有技巧可以使用。

虽然以上次获得的access_token为准，没有不利的副作用，但是会导致很多不必要的调用第三方接口，也会造成access_token在短时间内反复无效获取。

这个思维问题的梗意味着会导致很多不必要的调用第三方的接口。目标是减少不必要的通话。

优秀方案

方法一

没有最优的解决方案，但最好的方案适合业务场景。这是另一种方式：

1.在redis中查询access_token而不使用db，并且有直接返回；如果不存在，则添加分布式锁，同时检查是否存在，如果存在，则返回；没有调用第三方接口，写redis的同时设置相应的到期时间。

2.后台的定时任务刷新access_token，失败后调用接口一次(容错)。

3.图片上群友提供的答案中，为什么需要db？有的同学考虑redis宕机的场景或者主从数据丢失的场景，也可以用db做底层。

二、11/4 （大数据、高并发、mysql同步、库结构不一致）

业务背景

某公司大数据部门的青年学生现在要做一个高度并发的同步系统，将某项业务的数据同步到自己的系统中，然后在做各种复杂的操作后，提供接口给其他部门查询，每天的同步数据达到几千万。

整个预数据同步过程是完整地从一个mysql库同步到另一个mysql库(mysql-mysql)。

孟的初步架构设计是：听了一个mysql的binlog后，给MQ发消息，另一个服务把MQ里的数据写到自己的库中，但是现在出现了一个问题。

许多业务系统执行sql来添加、删除和更改mysql中相应的数据，但是孟晓发现自己库中的数据有时与业务端的数据不一致。

讨论

mq可能是连续的，或者消息处理可能很慢。

导致中间的延迟性的数据不一致

优秀方案

3. 其他：

   1、小猛同学是使用的RocketMQ，在监听binlog的服务中发送消息到RocketMQ的时候，一条数据的增删改路由到同一个messagequeue中保证消息的顺序性；

   2、A同学会问：如何解决监听到binlog后发送消息到RocketMQ的失败问题呢 答：发送消息时重试、多次重试失败后，提供兜底补偿方案

   3、B同学会问：发送binlog01、binlog02，01发送失败重试，02发送成功到时无序怎么办答：修改MQ的配置，需要等消息01发送成功后才能发送02；或者修改binlog为row模式，不使用insert update delete等逻辑上的binlog

   4、C同学会问：如何保证MQ中的消息不丢失答：RocketMQ的master、slave高可用，基于一致性算法raft来写commitlog

   5、D同学会问：如何保证消费messagequeue时消息的有序性答：单线程消费；如何提升系统性能答：单线程消费后，路由到队列中，在每个队列一个线程消费。如何解决数据丢失问题答：ack机制、优雅停机

   6、E同学会问：消费方执行本地落库的事务成功了，但是ack的时候失败，有重复消费怎么办 答：在消费方来保证幂等

   7、F同学会问：为啥要单独在搞个MQ直接用同步工具不就好了吗答：比如alibaba otter、离线dataX、kettle等

   8、补充说明：整个数据同步过程中，还是需要定期的比对数据；定期的全量同步数据；