只为成功找方法 不为失败找借口

服务端在接收到 Token 后，会先对 Token 进行拆分，然后使用相同的密钥和哈希算法计算 Token 中的数据的签名，并将其与 Token 末尾的签名串进行比较，以判断 Token 是否合法。这样，客户端就可以在以后的请求中使用新的 token。总的来说，token 认证的流程是在用户登录时获取 token，之后在 HTTP 请求头里携带 token，服务端在响应请求时对 token 进行验证并返回相应结果，同时可以在响应头中返回新的 token（用于更新之前的 token）。

分布式锁

限流分类限流的实现方案有很多种，磊哥这里稍微理了一下，限流的分类如下所示：合法性验证限流：比如验证码、IP 黑名单等，这些手段可以有效的防止恶意攻击和爬虫采集； 容器限流：比如 Tomcat、Nginx 等限流手段，其中 Tomcat 可以设置最大线程数（maxThreads），当并发超过最大线程数会排队等待执行；而 Nginx 提供了两种限流手段：一是控制速率，二是控制并发连接数； 服务端限流：比如我们在服务器端通过限流算法实现限流，此项也是我们本文介绍的重点。合法性验证限流为最常规的业务代

作者：敖丙链接：https://www.zhihu.com/question/54895548/answer/923987542来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。正文首先设计一个系统之前，我们需要先确认我们的业务场景是怎么样子的，我就带着大家一起假设一个场景好吧。场景我们现场要卖100件下面这个婴儿纸尿裤，然后我们根据以往这样秒杀活动的数据经验来看，目测来抢这100件纸尿裤的人足足有10万人。（南极人打钱！）你一听，完了呀，这我们.

一个分布式系统里面，节点组成的网络本来应该是连通的。然而可能因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。数据就散布在了这些不连通的区域中。这就叫分区。当你一个数据项只在一个节点中保存，那么分区出现后，和这个节点不连通的部分就访问不到这个数据了。这时分区就是无法容忍的。提高分区容忍性的办法就是一个数据项复制到多个节点上，那么出现分区之后，这一数据项就可能分布到各个区里。容忍性就提高了。然而，要把数据复制到多个节点，就会带来一致性的问题，就是多个节点上面的数据可能是不一致的。要

https://zhuanlan.zhihu.com/p/55958530广为人知的阿里分布式事务解决方案：GTS（Global Transaction Service），已正式推出开源版本，取名为“Fescar”，希望帮助业界解决微服务架构下的分布式事务问题，今天我们一起来深入了解。FESCAR on GitHubhttps://github.com/alibaba/fescar微服务倡导将复杂的单体应用拆分为若干个功能简单、松耦合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发。当

https://zhuanlan.zhihu.com/p/183753774?utm_source=wechat_session事务严格意义上的事务实现应该是具备原子性、一致性、隔离性和持久性，简称 ACID。原子性（Atomicity），可以理解为一个事务内的所有操作要么都执行，要么都不执行。 一致性（Consistency），可以理解为数据是满足完整性约束的，也就是不会存在中间状态的数据，比如你账上有400，我账上有100，你给我打200块，此时你账上的钱应该是200，我账上的钱应该是30

基于Redis使用分布式锁在当今已经不是什么新鲜事了。本篇文章主要是基于我们实际项目中因为redis分布式锁造成的事故分析及解决方案。背景：我们项目中的抢购订单采用的是分布式锁来解决的。有一次，运营做了一个飞天茅台的抢购活动，库存100瓶，但是却超卖了！要知道，这个地球上飞天茅台的稀缺性啊！！！事故定为P0级重大事故...只能坦然接受。整个项目组被扣绩效了~~事故发生后，CTO指名点姓让我带头冲锋来处理，好吧，冲~事故现场经过一番了解后，得知这个抢购活动接口以前从来没有出现过这种情况，但是这次为

系统唯一ID是我们在设计一个系统的时候常常会遇见的问题，也常常为这个问题而纠结。生成ID的方法有很多，适应不同的场景、需求以及性能要求。所以有些比较复杂的系统会有多个ID生成的策略。下面就介绍一些常见的ID生成策略。1. 数据库自增长序列或字段最常见的方式。利用数据库，全数据库唯一。优点：1）简单，代码方便，性能可以接受。2）数字ID天然排序，对分页或者需要排序的结果很有帮助。缺点：1）不同数据库语法和实现不同，数据库迁移的时候或多数据库版本支持的时候需要处理。2）在单.

面试题分布式事务了解吗？你们是如何解决分布式事务问题的？面试官心理分析只要聊到你做了分布式系统，必问分布式事务，你对分布式事务一无所知的话，确实会很坑，你起码得知道有哪些方案，一般怎么来做，每个方案的优缺点是什么。现在面试，分布式系统成了标配，而分布式系统带来的分布式事务也成了标配了。因为你做系统肯定要用事务吧，如果是分布式系统，肯定要用分布式事务吧。先不说你搞过没有，起码你得明白有哪几种方案，每种方案可能有啥坑？比如 TCC 方案的网络问题、XA 方案的一致性问题。面试题剖析分布式

分布式锁： Redis分布式锁 RedLock算法 1）获取当前时间戳，单位是毫秒 2）跟上面类似，轮流尝试在每个master节点上创建锁，过期时间较短，一般就几十毫秒 3）尝试在大多数节点上建立一个锁，比如5个节点就要求是3个节点（n / 2 +1） 4）客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了 5）要是锁建立失败了，那么就依次删除这个锁 6）只要别人建立了一把分布式锁，你就得不断轮询去尝试获取锁 互斥、不能死

之前网上看到很多写分布式事务的文章，不过大多都是将分布式事务各种技术方案简单介绍一下。很多朋友看了还是不知道分布式事务到底怎么回事，在项目里到底如何使用。所以这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务。首先说一下，这里可能会牵扯到一些 Spring Cloud 的原理，如果有不太清楚的同学，可以参考之前的文章：《拜托，面试请不...

这篇文章，就用大白话+手工绘图，并结合一个电商系统的案例实践，来给大家讲清楚到底什么是 TCC 分布式事务。首先说一下，这里可能会牵扯到一些 Spring Cloud 的原理，如果有不太清楚的同学，可以参考之前的文章：《拜托，面试请不要再问我Spring Cloud底层原理！》。业务场景介绍咱们先来看看业务场景，假设你现在有一个电商系统，里面有一个支付订单的场景。那对一个订单支...

从设计模式上来讲：其主要区别是是否有预提交的操作，XA有一个预提交的过程，在两阶段提交的过程中，有一个协调者在中间起到很重要的作用，当所有的事务都执行成功，会把执行成功的状态通知协调者，这个阶段是第一阶段，协调者监听到所有的事务执行成功后，执行第二阶段的commit，也就是说XA的两阶段提交是在第二阶段才执行commit而TCC的不同就在于其在第一阶段就commit了，没有预提交的过程，...

分布式可以分为：服务器分布式、缓存分布式（比如 Redis、memcache等）以及数据库分布式（比如mysql等），当然这些除了可以做分布式之外，还可以做集群同一个 IP 下不同端口号的，被认为是2个web应用，也属于分布式，典型的就是同一个局域网内的不同web应用，IP相同，但是可以通过设置不同的端口号（比如Tomcat，可以通过设置Tomcat 的 conf 文件里面的 port 来设置端口...

  在开发过程中经常会报一个项目拆分出来几个服务，拆分出来的服务不仅本项目可以使用，其它项目也可以使用，当然也会有某个服务调用另一个服务的Api的情况，遇到这种情况，分以下两个步骤：1.在pom.xml文件中添加要依赖的api的依赖，比如当前服务用到了字典服务的api<dependency> <groupId>com.billionhealth.service.ap...