wufaqidong1的博客

缓存中存有数据，缓存的数据值 = 数据库中的值；缓存中没有该数据，数据库中的值 = 最新值。缓存的数据值 ≠ 数据库中的值；缓存或者数据库存在旧的数据，导致线程读取到旧数据。❝为何会出现数据一致性问题呢？把 Redis 作为缓存的时候，当数据发生改变我们需要双写来保证缓存与数据库的数据一致。数据库跟缓存，毕竟是两套系统，如果要保证强一致性，势必要引入 2PC 或 Paxos 等分布式一致性协议，或者分布式锁等等，这个在实现上是有难度的，而且一定会对性能有影响。

JSON Web Token（缩写 JWT）是目前最流行的跨域认证解决方案，本文介绍它的原理和用法。

10 bit：表示当前服务器id，代表的是这个服务最多可以部署在 2^10 台服务器上，也就是 1024 台服务器

本文基于Spring Cloud Greenwich SR2，理论兼容Spring Cloud所有版本。

Spring Cloud Gatway内置的提供限流的能力，基于令牌桶算法实现。目前，它内置的，依赖Redis存储限流配置，以及统计数据。当然你也可以实现自己的RateLimiter，只需实现接口，或者继承。：想象有一个水桶，水桶以一定的速度出水（以一定速率消费请求），当水流速度过大水会溢出（访问速率超过响应速率，就直接拒绝）。：系统按照恒定间隔向水桶里加入令牌（Token），如果桶满了的话，就不加了。每个请求来的时候，会拿走1个令牌，如果没有令牌可拿，那么就拒绝服务。

线程池其实是一种池化的技术的实现，池化技术的核心思想其实就是实现资源的一个复用，避免资源的重复创建和销毁带来的性能开销。在线程池中，线程池可以管理一堆线程，让线程执行完任务之后不会进行销毁，而是继续去处理其它线程已经提交的任务。降低资源消耗。通过重复利用已创建的线程降低线程创建和销毁造成的消耗。提高响应速度。当任务到达时，任务可以不需要等到线程创建就能立即执行。提高线程的可管理性。线程是稀缺资源，如果无限制的创建，不仅会消耗系统资源，还会降低系统 的稳定性，使用线程池可以进行统一的分配，调优和监控。

该篇文章到这里就差不多结束了，我始终认为一图胜千言，因此我在文中基于上述分享的知识点，给大家做了个脑图，以便于帮助你回顾与总结。微服务与DDD的见解，我也是再三思考了才打算写出来，我清楚地知道有不少的DDD热衷者认为这门技术是多么的“神圣”，当然曾经我也是。但是，随着自己使用、接触的技术越多，越是发现技术并不是那么的唯一、神圣，促使我们能在这条道路走得更高更远的，是咱们的思维，是我们对这些技术做出适当的选择与使用，而不是想着“一招鲜吃遍天”，我们是技术的创造者与使用者，而不是概念名词的搬运工。

由单个应用拆分为一组小的服务（small）；每个服务在独立的进程运行，服务之间使用轻量级的通信机制（）；服务围绕业务构建，同时服务可以自动化独立部署（、automated）；可以使用不同的编程语言和数据存储（different）。轻量级（lightweight、small），通信协议和服务应用自身都应该是轻量级的。自治性（independently），能独立部署运行，且低耦合，服务之间互不影响。异构性/去中心化（different），可以根据业务特殊性，选择合适的开发语言和存储系统。

本文讲了防止数据重复提交的 6 种方法，首先是前端的拦截，通过隐藏和设置按钮的不可用来屏蔽正常操作下的重复提交。但为了避免非正常渠道的重复提交，我们又实现了 5 个版本的后端拦截：HashMap 版、固定数组版、双重检测锁的数组版、LRUMap 版和 LRUMap 的封装版。

上面主要从：垂直和水平，两个方向介绍了我们的系统为什么要分库分表。说实话垂直方向（即业务方向）更简单。在水平方向（即数据方向）上，分库和分表的作用，其实是有区别的，不能混为一谈。分库：是为了解决数据库连接资源不足问题，和磁盘IO的性能瓶颈问题。分表：是为了解决单表数据量太大，sql语句查询数据时，即使走了索引也非常耗时问题。此外还可以解决消耗cpu资源问题。分库分表：可以解决 数据库连接资源不足、磁盘IO的性能瓶颈、检索数据耗时 和 消耗cpu资源等问题。

接口幂等性问题，对于开发人员来说，是一个跟语言无关的公共问题。本文分享了一些解决这类问题非常实用的办法，绝大部分内容我在项目中实践过的，给有需要的小伙伴一个参考。不知道你有没有遇到过这些场景：有时我们在填写某些form表单时，保存按钮不小心快速点了两次，表中竟然产生了两条重复的数据，只是id不一样。我们在项目中为了解决接口超时问题，通常会引入了重试机制。第一次请求接口超时了，请求方没能及时获取返回结果（此时有可能已经成功了），为了避免返回错误的结果（这种情况不可能直接返回失败吧？

最近测试给我提了一个bug，说我之前提供的一个批量复制商品的接口，产生了重复的商品数据。追查原因之后发现，这个事情没想象中简单，可以说一波多折。

例如你的业务可能达不到 69 年之久，那么可用减少时间戳占用的位数，雪花算法服务需要部署的节点超过1024 台，那么可将减少的位数补充给机器码用。对于 MySQL 而言，一个表中的主键 id 一般使用自增的方式，但是如果进行水平分表之后，多个表中会生成重复的 id 值。注意，雪花算法中 41 位比特位不是直接用来存储当前服务器毫秒时间戳的，而是需要当前服务器时间戳减去某一个初始时间戳值，一般可以使用服务上线时间作为初始时间戳值。雪花算法的原理就是生成一个的 64 位比特位的 long 类型的唯一 id。

慢的本质查找的时间复杂度查找算法存储数据结构数据总量数据拆分高负载CPU、磁盘繁忙无论是关系型数据库还是NoSQL，任何存储系统决定于其查询性能的主要有三种：而决定于查找时间复杂度主要有两个因素：无论是哪种存储，数据量越少，自然查询性能就越高，随着数据量增多，资源的消耗（CPU、磁盘读写繁忙）、耗时也会越来越高。从关系型数据库角度出发，索引结构基本固定是B+Tree，时间复杂度是O(log n)，存储结构是行式存储。因此咱们对于关系数据库能优化的一般只有数据量。而高负载造成原因有高并发请求、复杂查询等，导致

2,)我还有一种想法，就是先插入完成后，根据条件查询出该批数据插入TABLE_M的生成的OID，之后这些OID去和temp匹配(按照顺序匹配，因为插入temp肯定是有序的插入)，之后修改temp中的TABLE_MOID,这样就可以把子数据插入到TABLE_M_LteCell,TABLE_M_GsmCell,TABLE_M_TdsCell中。，之后去维护主子表关系，改掉TABLE_M的OID的自增属性，插入，之后再添加上自增属性。这样，每个线程读取的都是MAX_OID表中的值，就不会产生冲突了。...

在HTTP/1.1中，对幂等性进行了定义。它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外），即第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。这里的副作用是不会对结果产生破坏或者产生不可预料的结果。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。幂等性是开发当中很常见也很重要的一个需求，尤其是支付、订单等与金钱挂钩的服务，保证接口幂等性尤其重要。...

对于分库分表来说，主要是面对以下问题•选择一个数据库中间件，调研、学习、测试；•设计你的分库分表的一个方案，你要分成多少个库，每个库分成多少个表，比如3个库，每个库4个表；•基于选择好的数据库中间件，以及在测试环境建立好的分库分表的环境，然后测试一下能否正常进行分库分表的读写；•完成单库单表到分库分表的迁移，双写方案；•线上系统开始基于分库分表对外提供服务；•扩容了，扩容成6个库，每个库需要12个表，你怎么来增加更多库和表呢？...

更重要的是，UUID不具有有序性，会导致B+树索引在写的时候有过多的随机写操作（连续的ID可以产生部分顺序写），还有，由于在写的时候不能产生有顺序的append操作，而需要进行insert操作，将会读取整个B+树节点到内存，在插入这条记录后会将整个节点写回磁盘，这种操作在记录占用空间比较大的情况下，性能下降明显。这个snowflake算法相对来说还是比较靠谱的，所以你要真是搞分布式id生成，如果是高并发啥的，那么用这个应该性能比较好，一般每秒几万并发的场景，也足够你用了。...

在电商、支付等领域，往往会有这样的场景，用户下单后放弃支付了，那这笔订单会在指定的时间段后进行关闭操作，细心的你一定发现了像某宝、某东都有这样的逻辑，而且时间很准确，误差在1s内；那他们是怎么实现的呢？定时任务关闭订单rocketmq延迟队列rabbitmq死信队列时间轮算法redis过期监听。...

【高可用MySQL解决方案】centos7配置mysql主从复制