面试701

Read Uncommitted(未提交读，读取未提交内容)13; 事务中的修改即使没有提交，其他事务也能看见，事务可以读到未提交的数据称为脏读13; 也存在不可重复读、幻读问题13; 13; Read Committed(提交读，读取提交内容)13; 一个事务开始后只能看见已经提交的事务所做的修改，在事务中执行两次同样的查询可能得到不一样的结果，也叫做不可重复读(前后多次读取，不能读到相同的数据内容)，也存幻读问题13; 13; Repeatable Read(可重复读,mysql默认的事务隔离级别)13; 解决脏读、不可重复读的问题，存在幻读的问题，使用 MMVC机制 实现可重复读13; 13; 幻读问题：MySQL的InnoDB引擎通过MVCC自动帮我们解决,即多版本并发控制13; 13; Serializable(可串行化)13; 解决脏读、不可重复读、幻读，可保证事务安全，但强制所有事务串行执行，所以并发效率低

脏读: 事务中的修改即使没有提交，其他事务也能看见，事务可以读到未提交的数据称为脏读13;​13;不可重复读: 同个事务前后多次读取，不能读到相同的数据内容，中间另一个事务也操作了该同一数据13;​13;幻读：当某个事务在读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围的记录时，发现两次不一样，产生幻读13;​13;​幻读和不可重复读的区别是：前者是一个范围，后者是本身，从总的结果来看, 两者都表现为两次读取的结果不一致

原子性Atomicity13;一致性Consistency13;隔离性Isolation13;持久性Durability

普通索引：最基本的索引,仅加速查询 13;唯一索引：加速查询，列值唯一，允许为空；组合索引则列值的组合必须唯一13;主键索引：加速查询，列值唯一，一个表只有1个，不允许有空值13;组合索引：加速查询，多条件组合查询13;覆盖索引：索引包含所需要的值，不需要“回表”查询，比如查询 两个字段，刚好是 组合索引 的两个字段13;全文索引：对内容进行分词搜索，仅可用于Myisam， 更多用ElasticSearch做搜索

索引好处：13; 快速定位到表的位置，减少服务器扫描的数据13; 有些索引存储了实际的值，特定情况下只要使用索引就能完成查询

索引缺点：13; 索引会浪费磁盘空间，不要创建非必要的索引13; 插入、更新、删除需要维护索引，带来额外的开销13; 索引过多，修改表的时候重构索引性能差

前缀索引，特别是TEXT和BLOG类型的字段，只检索前面几个字符，提高检索速度13; 尽量使用数据量少的索引，索引值过长查询速度会受到影响13; 选择合适的索引列顺序13; 内容变动少，且查询频繁，可以建立多几个索引13; 内容变动频繁，谨慎创建索引13; 根据业务创建适合的索引类型，比如某个字段常用来做查询条件，则为这个字段建立索引提高查询速度13; 组合索引选择业务查询最相关的字段

在多个索引的情况下，优化器一般会通过比较扫描行数、是否需要临时表以及是否需要排序等，来作为选择索引的判断依据13;选择索引 b，则需要在 b 索引上扫描 5w 条记录，然后同样回到主键索引上过滤掉不满足 a 条件的记录，因为索引有序，所以使用 b 索引不需要额外排序13;13;解决方法:13;使用force index a让mysql直接选择a索引来处理此处查询13;13;select * from testwnn321 where (a between 1000 and 2000) and (b between 50000 and 100000) order by b limit 1 走索引B13;13;select * from testwnn321 where (a between 1000 and 2000) and (b between 50000 and 100000) 走索引a

数据表有频繁的删除或更新操作导致的数据空洞造成的13;造成原因：分析器 explain 的结果预估的 rows 值跟实际情况差距比较大，分析器分析扫描行数用的是抽样调查13;解决方案：统计信息不对，那就修正。analyze table test 命令，可以用来重新统计索引信息

唯一索引:13;定义：UNIQUE索引可以强制执行值唯一的一列或多列。一个表可以有多个UNIQUE索引。13;场景：联系人的电子邮件唯一、联系人的身份证唯一 123@qq.com 数据库层面的严格唯一

查询上的区别:13;13;对唯一索引，由于索引定义了唯一性，查找到第一个满足条件的记录后，就会停止检索13;对普通索引，查找到满足条件的第一个记录’ab‘后，需查找下个记录，直到碰到第一个不满足k=’ab‘条件的记录13;结论：mysql采用page页（一页16K）为数据单位从磁盘load出数据，除非刚好值为’ab‘的记录在一页的最后一条数据，否则执行性能区别微乎其微

修改上的区别:13;13;对于唯一索引，所有更新操作要先判断该操作是否违反唯一性约束，唯一索引不会用change buffer13;若所修改的数据在内存中13; 找到索引对应该存储的位置，判断、到没有冲突，插入值，语句执行结束13; 找到索引对应该存储的位置，插入值，语句执行结束。13;13;若所修改的数据不在内存中13; 需要将数据页读入内存，判断到没有冲突，插入值，语句执行结束13; 将更新记录在change buffer，语句执行结束

数据库主从复制的目的:13; 容灾使用，用于故障切换13; 业务需要，进行读写分离减少主库压力

为什么会有同步延迟问题，怎么解决?

Mysql主从复制是基于binlog复制，难免出现复制数据不一致的风险，引起用户数据访问前后不一致的风险13;所以要定期开展主从复制数据一致性的校验并修复，避免这些问题13;13;解决方案之一，使用Percona公司下的工具13;13;pt-table-checksum工具进行一致性校验13; 原理：13; 主库利用表中的索引，将表的数据切割成一个个chunk(块)，然后进行计算得到checksum值。13; 从库也执相应的操作，并在从库上计算相同数据块的checksum，然后对比主从中各个表的checksum是否一致并存储到数据库，最后通过存储校验结果的表就可以判断出哪些表的数据不一致

pt-table-sync(在从库执行)工具进行修复不一致数据，可以修复主从结构数据的不一致，也可以修复非主从结构数据表的数据不一致13;13; 原理：在主库上执行数据的更改，再同步到从库上，不会直接更改成从的数据。在主库上执行更改是基于主库现在的数据，也不会更改主库上的数据，可以同步某些表或整个库的数据，但它不同步表结构、索引，只同步不一致的数据13;注意：13; 默认主库要检查的表在从库都存在，并且同主库表有相同的表结构13; 如果表中没有索引，pt-table-checksum将没法处理，一般要求最基本都要有主键索引13; pt-table-sync工具会修改数据，使用前最好备份下数据，防止误操作

pt-table-checksum怎么保证某个chunk的时候checksum数据一致性？13;当pt工具在计算主库上某chunk的checksum时，主库可能在更新且从库可能复制延迟，那该怎么保证主库与从库计算的是”同一份”数据，答案把要checksum的行加上for update锁并计算，这保证了主库的某个chunk内部数据的一致性

基本思路13;在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。13;13;伪代码如下：13;public void write( String key, Object data ){ redis.delKey( key ); db.updateData( data ); Thread.sleep( 500 ); redis.delKey( key );}

Kafka把topic中一个parition大文件分成多个小文件段，通过多个小文件段，就容易定期清除或删除已经消费完文件，减少磁盘占用。13;通过索引信息可以快速定位message13;producer生产数据，要写入到log文件中，写的过程中一直追加到文件末尾，为顺序写，官网数据表明。同样的磁盘，顺序写能到600M/S，而随机写只有100K/S

发送消息配置回调函数即可， 该回调方法会在 Producer 收到 ack 时被调用，为异步调用13;回调函数有两个参数 RecordMetadata 和 Exception，如果 Exception 是 null，则消息发送成功，否则失败

MANUAL poll()拉取一批消息，处理完业务后，手动调用Acknowledgment.acknowledge()先将offset存放到map本地缓存，在下一次poll之前从缓存拿出来批量提交13;MANUAL_IMMEDIATE 每处理完业务手动调用Acknowledgment.acknowledge()后立即提交13;RECORD 当每一条记录被消费者监听器（ListenerConsumer）处理之后提交13;BATCH 当每一批poll()的数据被消费者监听器（ListenerConsumer）处理之后提交13;TIME 当每一批poll()的数据被消费者监听器（ListenerConsumer）处理之后，距离上次提交时间大于TIME时提交13;COUNT 当每一批poll()的数据被消费者监听器（ListenerConsumer）处理之后，被处理record数量大于等于COUNT时提交13;COUNT_TIME TIME或COUNT满足其中一个时提交

如果在follower同步完成后，broker发送ack之前，leader发生故障，那么会造成数据重复

老版本记录在zk里面和本地

新版默认将offset保证在kafka的内置topic中，名称是 __consumer_offsets13;13;该Topic默认有50个Partition，每个Partition有3个副本，分区数量由参数offset.topic.num.partition配置13;通过groupId的哈希值和该参数取模的方式来确定某个消费者组已消费的offset保存到__consumer_offsets主题的哪个分区中13;由 消费者组名+主题+分区，确定唯一的offset的key，从而获取对应的值13;三元组：group.id+topic+分区号，而 value 就是 offset 的值

如果同一消费者组内，所订阅的消息是不相同的，在执行分区分配的时候不是轮询分配，可能会导致分区分配的不均匀

【按照主题】进行分配，如果不平均分配，则第一个消费者会分配比较多分区， 一个消费者监听不同主题也不影响，例如7个分区，同组内2个消费者13;13;topic-p0/topic-p1/topic-p2/topic-p3/topic-p4/topic-p5//topic-p613;13;c-1: topic-p0/topic-p1/topic-p2/topic-p313;13;c-2:topic-p4/topic-p5/topic-p613;13;弊端13;13;只是针对 1 个 topic 而言，c-1多消费一个分区影响不大13;如果有 N 多个 topic，那么针对每个 topic，消费者 C-1 都将多消费 1 个分区，topic越多则消费的分区也越多，则性能有所下降

有新得consumer加入13;旧的consumer挂了13;topic得partition增加13;分区个数得增加，对topic得订阅发生变化，最常遇到得就是 消费组成员得加入或者离开

Kafka 会进行一次分区分配操作，即 Kafka 消费者端的 Rebalance 操作 ，下面都会发生rebalance操作13;13;当消费者组内的消费者数量发生变化（增加或者减少），就会产生重新分配patition13;分区数量发生变化时(即 topic 的分区数量发生变化时)

13;可能重复消费: Consumer被踢出消费组，可能还没有提交offset，Rebalance时会Partition重新分配其它Consumer,会造成重复消费，虽有幂等操作但耗费消费资源，亦增加集群压力13;集群不稳定：Rebalance扩散到整个ConsumerGroup的所有消费者，因为一个消费者的退出，导致整个Group进行了Rebalance，并在一个比较慢的时间内达到稳定状态，影响面较大13;影响消费速度：频繁的Rebalance反而降低了消息的消费速度，大部分时间都在重复消费和Rebalance

第一步：所有消费成员都向Coordinator发送请求，请求入Consumer Group。一旦所有成员都发送了请求，Coordinator会从中选择一个Consumer担任Leader的角色，并把组成员信息以及订阅信息发给Leader。13;第二步：Leader开始分配消费方案，指明具体哪个Consumer负责消费哪些Topic的哪些Partition。一旦完成分配，leader会将这个方案发给Coordinator。Coordinator接收到分配方案之后会把方案发给各个Consumer，这样组内的所有成员就都知道自己应该消费哪些分区了。13;所以对于Rebalance来说，Coordinator起着至关重要的作用

合理设置消费者参数13;未能及时发送心跳而Rebalance13;session.timeout.ms 一次session的连接超时时间13;heartbeat.interval.ms 心跳时间，一般为超时时间的1/3，Consumer在被判定为死亡之前，能够发送至少 3 轮的心跳请求13;13;Consumer消费超时而Rebalance13;max.poll.interval.ms 每隔多长时间去拉取消息。合理设置预期值，尽量但间隔时间消费者处理完业务逻辑，否则就会被coordinator判定为死亡，踢出ConsumerGroup，进行Rebalance13;max.poll.records 一次从拉取出来的数据条数。根据消费业务处理耗费时长合理设置，如果每次max.poll.interval.ms 设置的时间较短，可以max.poll.records设置小点儿，少拉取些，这样不会超时。13;总之，尽可能在max.poll.interval.ms时间间隔内处理完max.poll.records条消息，让Coordinator认为消费Consumer还活着

接口层增加校验，数据合理性校验13;缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，设置短点的过期时间，防止同个key被一直攻击13;13;SpringCache解决方案:13;空结果也缓存，默认不配置condition或者unless就行13; cache:13; #使用的缓存类型13; type: redis13; #过时时间13; redis:13; time-to-live: 360000013; # 开启前缀，默以为true13; use-key-prefix: true13; # 键的前缀,默认就是缓存名cacheNames13; key-prefix: XD_CACHE13; # 是否缓存空结果，防止缓存穿透，默以为true13; cache-null-values: true

如何避免缓存穿透呢？ 一般有三种方法。13;13;1.如果是非法请求，我们在API入口，对参数进行校验，过滤非法值。13;2.如果查询数据库为空，我们可以给缓存设置个空值，或者默认值。但是如有有写请求进来的话，需要更新缓存哈，以保证缓存一致性，同时，最后给缓存设置适当的过期时间。（业务上比较常用，简单有效）13;3.使用布隆过滤器快速判断数据是否存在。即一个查询请求过来时，先通过布隆过滤器判断值是否存在，存在才继续往下查。13;布隆过滤器原理：它由初始值为0的位图数组和N个哈希函数组成。一个对一个key进行N个hash算法获取N个值，在比特数组中将这N个值散列后设定为1，然后查的时候如果特定的这几个位置都为1，那么布隆过滤器判断该key存在。

预防:13;存数据的过期时间设置随机，防止同一时间大量数据过期现象发生13;设置热点数据永远不过期，定时任务定时更新13;13;SpringCache解决方案：13;设置差别的过时时间13;比如CacheManager配置多个过期时间维度13;配置文件 time-to-live 配置13; cache:13; #使用的缓存类型13; type: redis13; #过时时间13; redis:13; time-to-live: 3600000

定期删除的扫描并不是遍历所有的键值对，这样的话比较费时而且太消耗系统资源。Redis服务器采用的是随机抽取的形式，每次100MS从过期字典中，取出20个键进行过期监测，过期字典中存储的是所有设置了过期时间的键值对。如果这批随机监查的数据中有25%比例过期，那么会再抽取20个随机键值进行检测和删除，并且会循环这个流程，直到抽取的这批数据中过期键键值小于25%，此次检测才算完成。

RDB 的优点13;适合大规模的数据恢复场景，如备份，全量复制等13;数据的一致性和完整性更高13;13;13;RDB缺点13;没办法做到实时持久化/秒级持久化。 在快照持久化期间修改的数据不会被保存，可能丢失数据13; 每次快照是一次全量备份，fork子进程进行后台操作，子进程存在开销

优点：13;数据更加安全13;当Redis AOF文件太大时，Redis能够在后台自动重写AOF13;AOF以易于理解和解析的格式，一个接一个地包含所有操作的日志13;13;缺点：13;AOF文件通常比同一数据集的等效RDB文件大13;根据确切的fsync策略，恢复的时候AOF可能比RDB慢

Redis的主从复制原理13;保存主节点（master）信息13;这一步只是保存主节点信息，保存主节点的ip和port。13;主从建立连接13;从节点（slave）发现新的主节点后，会尝试和主节点建立网络连接。13;发送ping命令13;连接建立成功后从节点发送ping请求进行首次通信，主要是检测主从之间网络套接字是否可用、主节点当前是否可接受处理命令。13;权限验证13;如果主节点要求密码验证，从节点必须正确的密码才能通过验证。13;同步数据集13;主从复制连接正常通信后，主节点会把持有的数据全部发送给从节点。13;命令持续复制13;接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。

主从同步的方式：13;主从模式中，Redis部署了多台机器，有主节点，负责读写操作，有从节点，只负责读操作。从节点的数据来自主节点，实现原理就是主从复制机制13;主从复制包括全量复制，增量复制两种。一般当slave第一次启动连接master，或者认为是第一次连接，就采用全量复制，全量复制流程如下：13;1.slave发送sync命令到master。13;2.master接收到SYNC命令后，执行bgsave命令，生成RDB全量文件。13;3.master使用缓冲区，记录RDB快照生成期间的所有写命令。13;4.master执行完bgsave后，向所有slave发送RDB快照文件。13;5.slave收到RDB快照文件后，载入、解析收到的快照。13;6.master使用缓冲区，记录RDB同步期间生成的所有写的命令。13;7.master快照发送完毕后，开始向slave发送缓冲区中的写命令;13;8.salve接受命令请求，并执行来自master缓冲区的写命令13;redis2.8版本之后，已经使用psync来替代sync，因为sync命令非常消耗系统资源，psync的效率更高。13;13;slave与master全量同步之后，master上的数据，如果再次发生更新，就会触发增量复制。

哨兵模式13;主从模式中，一旦主节点由于故障不能提供服务，需要人工将从节点晋升为主节点，同时还要通知应用方更新主节点地址。显然，多数业务场景都不能接受这种故障处理方式。Redis从2.8开始正式提供了Redis Sentinel（哨兵）架构来解决这个问题。13;13;哨兵模式，由一个或多个Sentinel实例组成的Sentinel系统，它可以监视所有的Redis主节点和从节点，并在被监视的主节点进入下线状态时，自动将下线主服务器属下的某个从节点升级为新的主节点。但是呢，一个哨兵进程对Redis节点进行监控，就可能会出现问题（单点问题），因此，可以使用多个哨兵来进行监控Redis节点，并且各个哨兵之间还会进行监控。13;13;哨兵模式就三个作用：13;发送命令，等待Redis服务器（包括主服务器和从服务器）返回监控其运行状态；13;哨兵监测到主节点宕机，会自动将从节点切换成主节点，然后通过发布订阅模式通知其他的从节点，修改配置文件，让它们切换主机；13;哨兵之间还会相互监控，从而达到高可用。

哨兵模式基于主从模式，实现读写分离，它还可以自动切换，系统可用性更高。但是它每个节点存储的数据是一样的，浪费内存，并且不好在线扩容。因此，Cluster集群应运而生，它在Redis3.0加入的，实现了Redis的分布式存储。对数据进行分片，也就是说每台Redis节点上存储不同的内容，来解决在线扩容的问题。并且，它也提供复制和故障转移的功能。13;Redis Cluster集群通过Gossip协议进行通信，节点之前不断交换信息，交换的信息内容包括节点出现故障、新节点加入、主从节点变更信息、slot信息等等。常用的Gossip消息分为4种，分别是：ping、pong、meet、fail

1.多个命令之间不是原子性操作，如setnx和expire之间，如果setnx成功，但是expire失败，且宕机了，则这个资源就是死锁

2.13;线程A 设置key 30秒过期，先加锁成功，但是执行了40秒13;线程B 设置key 30秒过期，由于线程A加锁过期，所以线程B加锁成功，执行方法50秒。13;这时候线程A执行完成了，但是线程B还没执行完成，结果就是 线程A删除了线程B加的锁

3.当线程A获取到正常值时，返回带代码中判断期间锁过期了，线程B刚好重新设置了新值，线程A那边有判断value是自己的标识，然后调用del方法，结果就是删除了新设置的线程B的值

4.13;原生代码+redis实现分布式锁使用比较复杂，且有些锁续期问题更难处理 推荐使用Redission

Redis锁的过期时间小于业务的执行时间该如何续期？

延时双删流程13;13;先删除缓存13;再更新数据库13;休眠一会（比如1秒），再次删除缓存。

删除缓存重试机制13;因为延时双删可能会存在第二步的删除缓存失败，导致的数据不一致问题。可以使用这个方案优化：删除失败就多删除几次呀,保证删除缓存成功就可以了呀~ 所以可以引入删除缓存重试机制13;13;删除缓存重试流程13;13;写请求更新数据库13;缓存因为某些原因，删除失败13;把删除失败的key放到消息队列13;消费消息队列的消息，获取要删除的key13;重试删除缓存操作

读取biglog异步删除缓存13;重试删除缓存机制还可以吧，就是会造成好多业务代码入侵。其实，还可以这样优化：通过数据库的binlog来异步淘汰key。13;13;以mysql为例吧13;13;可以使用阿里的canal将binlog日志采集发送到MQ队列里面13;然后通过ACK机制确认处理这条更新消息，删除缓存，保证数据缓存一致性

Redis 事务是不支持回滚的，不像 MySQL 的事务一样，要么都执行要么都不执行；13;13;Redis 服务端在执行事务的过程中，不会被其他客户端发送来的命令请求打断。直到事务命令全部执行完毕才会执行其他客户端的命令。

Redis 的事务不支持回滚。13;13;如果执行的命令有语法错误，Redis 会执行失败，这些问题可以从程序层面捕获并解决。但是如果出现其他问题，则依然会继续执行余下的命令。13;13;这样做的原因是因为回滚需要增加很多工作，而不支持回滚则可以保持简单、快速的特性。

冗余字段13;广播表(类似字典表)13;nosql汇总（mysql小表合并到es大表）

举例:重点是冗余信息，避免跨库13;订单需要用户的基本信息，但是分布在不同库上，就可以进行字段冗余，订单表冗余用户昵称、头像

冗余双写

举例：13;订单表 的partionKey是user_id，用户查看自己的订单列表方便13;但商家查看自己店铺的订单列表就麻烦，分布在不同数据节点13;方法：13;订单冗余存储在es上一份(Canal-server（模拟的从节点，主节点数据增删改都可以监听到，然后将数据推送kafka）-->kafka-->es)13;业务架构流程

时间范围：不用考虑扩容迁移13;区域范围：调整分片粒度，需要全量迁移

业务最多的是hash取模分片，因扩分库分表涉及到rehash过程13;13;分片数量建议可以成倍扩容策略，只需要【迁移部分数据】即可13;13;旧节点的数据，有一半要迁移至一个新增节点中

方案一、利用数据库主从

方案二、对外发布公告，停机迁移

分库规则 根据 user_id 进行分库

分表规则 根据 product_order_id 订单号进行分表

分库表后的查询删除操作

指所有的分片数据源中都存在的表，表结构和表中的数据在每个数据库中均完全一致13;适用于数据量不大且需要与海量数据的表进行关联查询的场景13;例如：字典表、配置表

broadcast-tables=ad_config(表名)

指分片规则一致的主表和子表13;比如product_order表和product_order_item表，均按照order_id分片，则此两张表互为绑定表关系13;绑定表之间的多表关联查询不会出现笛卡尔积关联，关联查询效率将大大提升

# 指定product_order_item表的数据分布情况13;spring.shardingsphere.sharding.tables.product_order_item.actual-data-nodes=ds$->{0..1}.product_order_item_$->{0..1}13;spring.shardingsphere.sharding.tables.product_order_item.table-strategy.inline.sharding-column=product_order_id13;spring.shardingsphere.sharding.tables.product_order_item.table-strategy.inline.algorithm-expression=product_order_item_$->{product_order_id % 2}13;13;#绑定表13;spring.shardingsphere.sharding.binding‐tables[0] = product_order,product_order_item

只支持【单分片键】使用Groovy的表达式，提供对SQL语句中的 =和IN 的分片操作支持13;13;可以通过简单的配置使用，无需自定义分片算法，从而避免繁琐的Java代码开发13;13;prouduct_order_$->{user_id % 8}` 表示订单表根据user_id模8，而分成8张表，表名称为`prouduct_order_0`到`prouduct_order_7

分表：13; PreciseShardingAlgorithm 精准分片 是必选的，用于处理=和IN的分片13;实现PreciseShardingAlgorith接口，重写doSharding方法13;dataSourceNames 数据源集合13; 在分库时值为所有分片库的集合 databaseNames13; 分表时为对应分片库中所有分片表的集合 tablesNames13;13;shardingValue 分片属性，包括13; logicTableName 为逻辑表，13; columnName 分片健（字段），13; value 为从 SQL 中解析出的分片健的值13;使用配置:13;# 指定product_order表的数据分布情况，配置数据节点,在 Spring 环境中建议使用 $->{...}13;spring.shardingsphere.sharding.tables.product_order.actual-data-nodes=ds0.product_order_$->{0..1}13;13;#指定精准分片算法(水平分表)13;spring.shardingsphere.sharding.tables.product_order.table-strategy.standard.sharding-column=id13;spring.shardingsphere.sharding.tables.product_order.table-strategy.standard.precise-algorithm-class-name=net.wnn.strategy.CustomTablePreciseShardingAlgorithm13;

分库:13;13;#指定全部数据节点，水平分库分表13;spring.shardingsphere.sharding.tables.product_order.actual-data-nodes=ds$->{0..1}.product_order_$->{0..1}13;13;# 分库分片健13;spring.shardingsphere.sharding.tables.product_order.database-strategy.standard.sharding-column=user_id13;# 分库分片算法13;spring.shardingsphere.sharding.tables.product_order.database-strategy.standard.precise-algorithm-class-name=net.wnn.strategy.CustomDBPreciseShardingAlgorithm

RangeShardingAlgorithm 范围分片13;13;用于处理BETWEEN AND语法，没配置的话会报错 Cannot find range sharding strategy in sharding rule.13;主要是会根据 SQL中给出的分片健值范围值处理分库、分表逻辑

Set<String> result = new LinkedHashSet<>();13; // between 起始值13; Long lower = rangeShardingValue.getValueRange().lowerEndpoint();13; // between 结束值13; Long upper = rangeShardingValue.getValueRange().upperEndpoint();13;13; // 循环范围计算分库逻辑13; for (long i = lower; i <= upper; i++) {13; for (String databaseName : dataSourceNames) {13; if (databaseName.endsWith(i % dataSourceNames.size() + "")) {13; result.add(databaseName);13; }13; }13; }13; return result;13; }

#精准水平分表下，增加一个范围分片13;spring.shardingsphere.sharding.tables.product_order.table-strategy.standard.range-algorithm-class-name=net.wnn.strategy.CustomRangeShardingAlgorithm

这种分片策略无需配置文件进行配置分片健，分片健值也不再从 SQL中解析，外部手动指定分片健或分片库，让 SQL在指定的分库、分表中执行13;通过Hint代码指定的方式而非SQL解析的方式分片的策略13;Hint策略会绕过SQL解析的，对于这些比较复杂的需要分片的查询，Hint分片策略性能可能会更好13;可以指定sql去某个库某个表进行执行

implements HintShardingAlgorithm<Long> 重写 doSharding13;

@param dataSourceNames 数据源集合13; 在分库时值为所有分片库的集合 databaseNames13; 分表时为对应分片库中所有分片表的集合 tablesNames

@param hintShardingValue 分片属性，包括logicTableName 为逻辑表，13; columnName 分片健（字段），hit策略此处为空 ""13; value 【之前】都是 从 SQL 中解析出的分片健的值,用于取模判断13; HintShardingAlgorithm不再从SQL 解析中获取值，而是直接通过13; hintManager.addTableShardingValue("product_order", 1)参数进行指定

配置# Hint分片算法13;spring.shardingsphere.sharding.tables.product_order.table-strategy.hint.algorithm-class-name=net.xdclass.strategy.CustomTableHintShardingAlgorithm13;spring.shardingsphere.sharding.tables.product_order.database-strategy.hint.algorithm-class-name=net.xdclass.strategy.CustomDBHintShardingAlgorithm13;

@Test13; public void testHint() {13; // 清除掉历史的规则13; HintManager.clear();13; //Hint分片策略必须要使用 HintManager工具类13; HintManager hintManager = HintManager.getInstance();13; // 设置库的分片健,value用于库分片取模，13; hintManager.addDatabaseShardingValue("product_order",3L);13;13; // 设置表的分片健,value用于表分片取模，13; //hintManager.addTableShardingValue("product_order", 7L);13; hintManager.addTableShardingValue("product_order", 8L);13;13; // 如果在读写分离数据库中，Hint 可以强制读主库（主从复制存在一定延时，但在业务场景中，可能更需要保证数据的实时性）13; //hintManager.setMasterRouteOnly();13;13; //对应的value只做查询，不做sql解析13; productOrderMapper.selectList(new QueryWrapper<ProductOrder>().eq("id", 66L));13; }

程序计数器13;记录每个线程当前执行的指令

虚拟机栈13;记录每个栈帧中的局部变量、方法返回地址等

本地方法栈13;调用操作系统原生本地方法所需要的内存区域

堆 内存区 也是GC垃圾回收的主战场，用于存放类的实例对象

方法区 主要存放类结构、类成员定义 static静态成员等

运行时常量池

在对象中添加一个引用计数器，对象被引用，计数器+1 引用失效 计数器-1，统计计数器为0的对象作为结果13;缺点：难以解决对象之间的相互循环引用

通过GC Root作为起点13;通过起点向下遍历，走过的路径作为引用链13;仅判定引用链包含的对象作为可达对象

GC Root范围13;虚拟机栈中的引用对象13;方法区中类静态属性引用的对象13;方法区中常量引用的对象13;本地方法中JNI引用的对象13;被synchronize持有的对象

范围： 程序计数器13;虚拟机栈13;本地方法栈13;特点：随线程而生，随线程而灭13;原因：编译期间即可知道内存占用大小13;内存的分配和回收都具有确定性

范围：虚拟机堆 静态区 常量池13;运行期间动态创建，内存的分配和回收具有不确定性

优点：13;简单快速13;缺点：13;产生很多内存碎片

优点：13;避免了很多内存碎片的问题13;缺点：13;内存浪费严重，相当于只能使用50%的内存

将垃圾清理后，同时将剩下的存活对象向一端进行整理挪动，保证它们占用的空间连续13;优点：13;节约了内存，并避免了内存碎片问题13;缺点：13;整理过程会降低GC效率

分代诞生原因：13;内存中的对象有些生命周期很短，比如一些局部变量、临时对象13;而另外一些则会存活很久，比如websocket长连接中的connection对象13;13;内存被分为三块，年轻代 老年代和永久代 ，其中年轻代被分为 eden 、s0、s1三个区13;jdk1.8后元空间取代了永久代

Serial、ParNew、Parellel Scavenge

Serial Old、Parallel Old、CMS

G1 jdk1.9默认13;初始标记：仅仅标记GCR能直接关联到的对象，修改TAMS指针的值，让下一个阶段用户线程并发运行时，能正确的在可用的Region中分配新对象。这个阶段需要停顿线程，但是 耗时 很短13;而且是借用Minor GC的时候同步完成的，所以G1收集器再这个阶段时间并没有额外的停顿13;并发标记：从GCR开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象扫描完成以后，并发时有引用变动的对象13;会产生漏标的问题，G1中会使用STAB算法来解决。13;最终标记：对用户线程做个短暂的暂停，用于处理并发标记阶段仍遗留下的最后那少量的STAB记录，多个线程同时标记。13;筛选回收：负责更新Region的统计数据，对各个Region的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region构成回收集13;然后把决定回收的那一个部分Region的存活对象复制到空的Region中，再清理掉整个旧的Region的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多个收集器线程并行完成的。13;13;使用场景：实时数据占用超过一半的堆空间，对象分配或者晋升的速度变化大

存在的问题

动态调整大小得Region13;G1中每个Region的大小都是固定的，创建和销毁Region，可以动态调整大小，内存使用更高效13;不分代，去掉了RSets13;G1中每个Region需要借助额外的RSets来记录是谁引用了我，占用了额外的内存空间，每次对象移动时候，RSets也需要更新，会产生开销

跨代引用13;堆空间通常被划分为新生代和老年代，所谓跨代引用，一般是指老年代对象引用了新生代的对象。如下图的X和Y引用：13;13;新生代的垃圾收集通常很频繁（朝生夕死），如果老年代对象引用了新生代的对象，那么在回收新生代（Young GC）的时候，需要跟踪从老年代到新生代的所有引用

跨代引用主要存在于Young GC的过程中，除了常见的GC Roots之外，如果老年代有对象引用了的新生代对象，那么老年代的对象也属于GC Roots（如上图中的老年代对象B和C）对象，但是如果每次进行Young GC我们都需要扫描一次老年代的话，那我们进行垃圾回收的代价实在是太大了，因此收集器在新生代上建立一个全局的称为记忆集的数据结构来记录这种引用关系。13;13;Rset(Remember Set)，简单来说就是一种抽象数据结构用来存老年代对象对新生代的引用（即引用X和Y）。

卡表（CardTable）在很多资料上被认为是对记忆集的实现（它定义了记忆集的记录精度、与堆内存的映射关系等）13;，由于在Young GC的过程中，需要扫描整个老年代，效率非常低，所以 JVM 设计了卡表，如果一个老年代的卡表中有对象指向新生代，13; 就将它设为 Dirty（标志位 1，反之设为0），下次扫描时，只需要扫描卡表上是 Dirty 的内存区域即可。13; 而卡表和记忆集的关系可以理解为一个HashMap

AQS的全称为（AbstractQueuedSynchronizer），这个类在java.util.concurrent.locks包下面。13;它是一个Java提高的底层同步工具类，比如CountDownLatch、ReentrantLock，Semaphore，13;ReentrantReadWriteLock，SynchronousQueue，FutureTask等等皆是基于AQS的

简单来说：是用一个int类型的变量表示同步状态，并提供了一系列的CAS操作来管理这个同步状态对象13;一个是 state（用于计数器，类似gc的回收计数器）13;一个是线程标记（当前线程是谁加锁的），13;一个是阻塞队列（用于存放其他未拿到锁的线程

acquire(int arg)好比加锁lock操作13;tryAcquire()尝试直接去获取资源，如果成功则直接返回,AQS里面未实现但没有定义成abstract，因为独占模式下只用实现tryAcquire-tryRelease，而共享模式下只用实现tryAcquireSharedtryReleaseShared，类似设计模式里面的适配器模式13;addWaiter() 根据不同模式将线程加入等待队列的尾部，有Node.EXCLUSIVE互斥模式、13;Node.SHARED共享模式；如果队列不为空，则以通过compareAndSetTail方法以CAS将当前线程节点加入13;到等待队列的末尾。否则通过enq(node)方法初始化一个等待队列13;acquireQueued()使线程在等待队列中获取资源，一直获取到资源后才返回,如果在等待过程中被中断，则返回true，否则返回false13;release(int arg)好比解锁unlock13;独占模式下线程释放指定量的资源，里面是根据tryRelease()的返回值来判断该线程是否已经完成释13;放掉资源了；在自义定同步器在实现时，如果已经彻底释放资源

synchronize关键之可以用于修饰普通方法、静态方法以及普通代码块，分别锁住的是：13;修饰普通方法：锁住对象的实例（new 出多少个对象，各个对象之间不会相互竞争）13;修饰静态方法：锁住整个类（new 出多少个对象，各个对象之间会相互竞争）13;修饰代码块： 锁住一个对象 synchronized (object) 即synchronized后面括号里的对象

synchroized独占式悲观锁，通过JVM隐式实现，只允许同一个时刻只有一个线程操作资源13;只能是非公平锁13;可以用于修饰方法，修饰代码块等13;无需手动释放锁13;不知道是否成功获得了锁13;不支持中断锁

ReentranTLock 是Lock的默认实现方式之一，是基于AQS实现的，默认通过非公平锁13;可设置为公平锁13;只能修饰代码块13;需要手动枷锁和释放锁，如果忘记释放锁，则会造成资源被永久占用13;可以知道是否成功获得了锁13;支持中断锁

synchronized的锁可重入、不可中断、非公平，每次使用会自动释放锁13;Lock锁可重入、可中断、可公平，每次使用需要自己加锁以及释放锁，一般情况下需放在finally里进行锁的释放，否则，可能因为未能正确释放锁而导致程序出问题。13;Lock可以实现有限时间内的获取锁的等待，在指定的时间内如果获取不到锁，会返回false

ReentrantReadWriteLock13;1、读写锁接口ReadWriteLock接口的一个具体实现，实现了读写锁的分离，13;2、支持公平和非公平，底层也是基于AQS实现13;3、允许从写锁降级为读锁13;流程：先获取写锁，然后获取读锁，最后释放写锁；但不能从读锁升级到写锁13;4、重入：读锁后还可以获取读锁；获取了写锁之后既可以再次获取写锁又可以获取读锁13;核心：读锁是共享的，写锁是独占的。 读和读之间不会互斥，读和写、写和读、写和写之间才会互斥，13;主要是提升了读写的性能

ReentrantLock是独占锁且可重入的，相比synchronized而言功能更加丰富也更适合复杂的并发场景，但13;是也有弊端，假如有两个线程A/B访问数据，加锁是为了防止线程A在写数据， 线程B在读数据造成的数据不13;一致； 但线程A在读数据，线程C也在读数据，读数据是不会改变数据没有必要加锁，但是还是加锁了，降低13;了程序的性能，所以就有了ReadWriteLock读写锁接口

13;悲观锁:它认为线程很容易把数据修改掉，因此在整个数据被修改的过程中都会采取锁定的状态，直到线程使用完，其它才可以使用，举例：synchronized13;乐观锁:和悲观锁的概念相反，乐观锁认为一般情况下数据在修改时不会出现冲突，所以在数据访问之前不会加锁，只是在数据提交更改时候，才会对数据进行检测，举例 ReadWriteLock 读写锁13;可重入锁:也叫递归锁，指的是同一个线程在外面的函数获取了锁之后，那么内层的函数也可以继续获得此锁 举例 ReentrantLock 和 synchronized 都是可重入锁13;独占锁和共享锁:只能被单线程持有的锁叫独占锁，可以被多线程持有的锁叫共享锁 ，独占锁指的是任何时候最多只能有一个线程持有该锁，比如ReentrantLock就是独占锁 ，而ReadWriteLock读写锁允许同一个时间段有多个线程进行读操作，属于共享锁

NEW 新建，线程被创建出来，但是尚未启动时候的线程状态13;Runnable 就绪，表示可以运行的线程状态，可能正在运行或者是在排队等待操作系统给它分配CPU资源13;Blocked 阻塞，阻塞等待锁的线程状态，表示出于阻塞状态的线程正在等待监视器锁，比如等待执行的synchronized代码块或者synchroized标记的方法13;Waiting 等待，一个处于等待状态的线程正在等待另外一个线程执行某个特定的动作，比如调用了wait join方法13;Terminated 终止，线程执行完成

13;1.二者状态形成的调用方法不同，其次Block可以理解为当前线程还处于活跃状态，只是在阻塞等待其他线程使用完某个锁资源13;2.而Waiting则是因为自身调用了wait或者join进入了等待状态，只能等待其他线程执行某个特定的动作才能被继续唤醒

1.从执行效果来说，start方法可以开启多线程，让线程从new状态转换到Runnable状态，而run方法只是一个普通方法13;2.调用次数不同，start方法不能被调用多次，否则会抛出IllegalStateException，而run方法可以进行多次调用，因为它只是一个普通方法

wait只能在同步块（synchronize）环境中被调用，而sleep不需要。13;wait方法在进入wait状态的时候会释放对象的锁，但是sleep方法不会。13;进入wait状态的线程能够被notify和notifyAll线程唤醒，但是进入sleeping状态的线程不能被notify方法唤醒，到期之后自动继续执行

1.线程的优先级可以理解为线程抢占CPU时间片的概率，优先级越高的线程优先执行的概率越大，但是并不能保证优先级高的线程一定先执行13;2.可以通过Thread.setPriority()来设置优先级 最小是1 最大是10 默认是5

1.join 在一个线程中调用other.join()，这时候当前线程会让出执行权给other线程，直到Other线程执行完了或者过了超时时间后再继续执行当前线程,join方法的底层还是通过wait来实现的13;2.yield方法表示给线程调度器一个当前线程愿意出让CPU使用权的按时，但是线程调度器可能会忽略这个暗示,代码中加入yield测试会发现每次执行结果都不一样，这是因为yield执行不稳定，调度器不一定UI采纳13;yield出让CPU使用权的建议

newFixedThreadPool13;一个定长线程池，可控制线程最大并发数13;newCachedThreadPool13;一个可缓存线程池13;newSingleThreadExecutor13;一个单线程化的线程池，用唯一的工作线程来执行任务13;newScheduledThreadPool13;一个定长线程池，支持定时/周期性任务执行

execute()不能接收返回值13;submit()方法可以接收线程池执行的返回值,返回的是Future<>，可通过future.get()

Executors创建的线程池底层也是调用 ThreadPoolExecutor，只不过使用不同的参数、队列、拒绝策略等,如果使用不当，会造成资源耗尽问题；13;直接使用ThreadPoolExecutor让使用者更加清楚线程池允许规则，常见参数的使用，避免风险

newFixedThreadPool和newSingleThreadExecutor:13;队列使用LinkedBlockingQueue，队列长度为 Integer.MAX_VALUE，可能造成堆积，导致OOM13;newScheduledThreadPool和newCachedThreadPool:13;线程池里面允许最大的线程数是Integer.MAX_VALUE，可能会创建过多线程，导致OOM

Abortpolicy 默认的拒绝策略，终止策略，线程池会抛出异常并终止进行。13;CallerRunsPolicy把任务交给当前线程来执行13;DiscardPolicy 忽略此任务13;DiscardOldestPolicy 忽略最早的任务

自定义拒绝策略，只需要新建一个RejectedExceutionHandler对象，然后重写它的rejectedExecution方法即可

SpringBoot本质上是Spring框架的延伸和扩展，是基于Spring的，使用它可以不再依赖Spring应用程序中的XML配置，可以更快更高效的开发Spring

SpringBoot只需要添加一个Starter模块支持后，在项目构建期，就会把所有其他依赖项自动添加到项目中13;比如测试库，如果是Spring项目，我们通常要添加Spring-Test,JUint,Mockito库，而如果是SpringBoot项目的话，只需要添加spring-boot-starter-test即可，它会自动帮我们把其他依赖项添加到项目中

SpringBoot内嵌默认的容器 Tomcat,可以通过修改pom.xml来移除内嵌Tomcat更换为其它容器

1.创建并启动计时监控类13;2.声明应用上下文对象和异常报告集合13;3.设置系统属性headless的值13;4.创建所有spring运行监听器，并发布启动事件13;5.初始化默认应用的参数类13;6.准备环境 ，创建配置并且绑定环境，通过property source和profiles等配置文件13;7.创建Banner的打印类13;8.创建应用上下文，根据不同的应用类型来创建不同的ApplicationContext上下文对象13;9.实例化异常报告器13;10.准备应用上下文13;11.刷新应用上下文13;12.应用上下文刷新之后的事件处理13;13.停止计时监控类13;14.输出日志信息13;15.发布应用上下文启动完成事件13;16.执行所有Runner运行器13;17.发布应用上下文就绪事件13;18.返回应用上下文对象

假如加载因子是0.5，hashmap的初始化容量是16,那么,当hashmap中有16*0.5=8个元素的时候，就hashmap就会扩容13;13;之所以是0.75而不是0.5 这其实是出于容量和性能之间平衡的结果。当加载因子变大的时候，扩容门槛就提高了，此时发生hash冲突的几率就会上升。需要更复杂的数据结构来存储元素，这样对元素的操作时间就会增加，运行效率降低13;而当加载因子比较小的时，扩容的门槛会比较低，因此会占用更多的空间，此时元素存储就比较稀疏，发生Hash冲突的可能性就比较小，因此可操作性能会比较高13;

对Key进行hash操作13;先判断table是否非空，然后判断第一个元素是否是要查询的元素，是就返回，不是就继续下一个节点非空判断13;判断第一个节点是树结构，是则使用getTreeNode直接获取相应的数据13;非树结构的话，循环节点判断do while ,判断到hash相等且key相同 则返回此节点

对Key进行hash操作13;判断hash表是否为空，为空则进行扩容创建13;不为空，进行hash分析命中的那个桶中是否有值，没有则直接保存插入数据13;有值则判断key值是否一样，一样则覆盖。13;不一样则判断是否为红黑树节点，是树节点则直接插入13;不是树节点则遍历链表插入数据，插入的时候判断表长度是否大于8，size大于64 ，是则转为红黑树13;最后判断是否要扩容，否就结束插入流程 ，是就进行扩容