Java知识全面总结

当用户以HTTP请求方式去请求HTTPS资源的时候；这个时候Tomcat就会重定向以该端口重新发送HTTPS请求

设置JVM的垃圾回收参数

设置JVM的垃圾回收参数

//NIO protocol="org.apache.coyote.http11.Http11NioProtocol" //NIO2 protocol="org.apache.coyote.http11.Http11Nio2Protocol"

protocol="org.apache.coyote.http11.Http11AprProtocol"

这个sql语句会向三个DB 发送数据请求，

mycat会把sql转成 select * from db1.user_info select * from db2.user_info select * from db3.user_info

然后mycat 在把结果集封装在一起，返回给客户端；

mycat 就会根据分片规则，定位到具体的数据库，然后直接只给一个数据库发送请求；

往三个库里面发三个select请求  获取三对 六条结果

随机抽取一对返回给客户端

先发送三个select 每个都是最大的两条 然后返回给mycat  进行综合评选拿出最大的俩 返回给客户端

sql解析，也就是跳过前面5条，取6，7条数据；

如果mycat 向三个数据库发送都是 limit5,2 则会出现问题，

关联的查询的表，需要把能够关联在一起的数据放在一个库里面，如果不能保证这点， 那么就需要 放弃这两个表数据分库

通过锁定索引记录来实现；锁定某一个索引记录

使用场景

作用

通过索引记录来实现

对一定范围内数据进行加锁，即使这数据不存在也是会加锁

Select * from emp where empid > 100 for update;会对empid大于100的都加上间隙锁，即使记录不存在也会添加

使用场景

作用

相当于一个记录锁+间隙锁

使用场景

作用

给数据行加行级锁之前需要取道该表的意向共享锁

给数据行家排他锁之前需要取到该表的意向排他锁

记录后事物执行之后的状态，用来记录未写入 datafile 的已成功的事物更新的数据；

在MySQL宕机时候，还有数据没有写入磁盘，可以通过重做日志重做，从而达到数据的持久化

事物开始的时候就会有日志生成，随着事物的进行的过程中，日志逐渐写入redolog中

当某个事物对应的数据写入 datafile中后，redolog的使命已经完成了，重做日志的空间就会被重用

数据库的每一次修改(insert,update,delete)操作,在落到磁盘之前都会先记录到undolog

记录信息修改之前和修改之后的数据

根据undolog日志做数据库的逆向操作，原来的insert操作变成delete操作，delete变成insert，update变成逆向update

根据主键排序做的索引，特殊的唯一索引

强制让表中某个字段值不能重复

根据某一列字段建立的索引

根据非主键索引查询得到主键；再根据主键去做查询；

全局锁就是对整个数据库实例加锁

MySQL提供了一个加全局读锁的方法，命令是 Flush tables with read lock (FTWRL)。当你需要让整个库处于只读状态的时候，可以使用这个命令，其他线程的数据更新（数据的增删改）、数据定义（包括建表、修改表结构等）和更新类事务的提交会被阻塞

使用场景

表锁是由MySQL本身来实现

表锁具体实现

记录锁

间隙锁

Next-key锁

innerDB的行锁是在索引上加锁，如果一张表没有索引，那么加的是表锁； innerDB默认加的就是行锁

innerDB如果没有主键，那么还会有一个rowId的唯一表示；

1.一次封锁发，事物一次就占据所有字资源，要么全部封锁，要么全不封锁

2.顺序加锁，定义锁的加锁顺序，只能这么来

3.时间戳

A给B转钱，A成功的把钱给了B,B也成功的收到了A的钱

A给B转1000块钱，A的账户扣了1000块，B的账户多了1000块

逆向记录mysql执行的sql语句；insert 语句生成对应的delete语句，delete语句生成insert语句，update更新语句生成更新回来的语句；

先写日志，再写磁盘

同时开启AB两个事物，A事物可以看到B事物没有做事物提交的数据

A事物读取B事物更新的数据，B又做了回滚，A事物读到的是脏数据；

每次访问数据的时候，都认为是查询操作，其他事物也能访问当前事物的数据；造成的数据不一致性，采取的方式是修改数据之后，对修改的数据进行回滚操作

1.读操作过多的情况下，能够显著提高效率

2.采取时候回滚操作来来解决事物冲突问题

通过在需要更新的表中设立相关的数据版本号来做操作

可在分布式场景下控制多个服务对相同数据的修改是线性执行的；

数据库的版本锁

每次访问数据的时候，都会对数据进行加锁操作

1.采取的是提前预防冲突

2.严格的控制其他事物对当前事物的访问，避免大量的数据回滚

3.其他事物，在某些情况下还是可以访问当前数据

通过数据库本身的锁机制来实现悲观控制

单体服务的时候就实现对并发事物的悲观控制

读取记录的可见版本（可能是历史版本，也可能是当前版本）不用加锁

不加锁的select操作

加锁的读操作

加锁读取记录的最新版本，保证其他事物不会并发修改这条记录；

特殊的读操作

插入/更新/删除

表示select或者是where中含有子查询

表示where后面的in条件有子查询

CREATE TABLE `user` ( `id` int(11) NOT NULL, `NAME` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;insert into user values(1,'shenjian');insert into user values(2,'zhangsan');insert into user values(3,'lisi');

explain select * from user where id=1;

CREATE TABLE `user` ( `id` int(11) NOT NULL, `NAME` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;insert into user values(1,'shenjian');insert into user values(2,'zhangsan');insert into user values(3,'lisi');CREATE TABLE `user_ex` ( `id` int(11) NOT NULL, `age` int(11) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;insert into user_ex values(1,18);insert into user_ex values(2,20);insert into user_ex values(3,30);insert into user_ex values(4,40);insert into user_ex values(5,50);

EXPLAIN SELECT * FROM USER,user_ex WHERE user.id=user_ex.id;

EXPLAIN SELECT * FROM USER,user_ex WHERE user.id=user_ex.id;

CREATE TABLE `user` ( `id` int(11) NOT NULL, `name` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;insert into user values(1,'shenjian');insert into user values(2,'zhangsan');insert into user values(3,'lisi');insert into user values(4,'wangwu');insert into user values(5,'zhaoliu');

explain select * from user where id between 1 and 4;explain select * from user where id in(1,2,3);explain select * from user where id > 3;

CREATE TABLE `user` ( `id` int(11) NOT NULL, `name` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;insert into user values(1,'shenjian');insert into user values(2,'zhangsan');insert into user values(3,'lisi');insert into user values(4,'wangwu');insert into user values(5,'zhaoliu');

explain count (*) from user;

CREATE TABLE `user` ( `id` int(11) DEFAULT NULL, `name` varchar(20) DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8;insert into user values(1,'shenjian');insert into user values(2,'zhangsan');insert into user values(3,'lisi');CREATE TABLE `user_ex` ( `id` int(11) DEFAULT NULL, `age` int(11) DEFAULT NULL) ENGINE=InnoDB DEFAULT CHARSET=utf8;insert into user_ex values(1,18);insert into user_ex values(2,20);insert into user_ex values(3,30);insert into user_ex values(4,40);insert into user_ex values(5,50);

explain select * from user,user_ex where user.id=user_ex.id;

被用户定义的 sql语句的集合

某个时间所触发的操作；一种特殊的存储过程；

基于基表的一种逻辑表或者虚拟表

子主题

管理用户对数据库的连接

用户权限管理

根据语句对sql语句中能够做优化的SQL自动做优化

优化器分类

包括词法分析，语法分析

mysql缓存查询到的数据永远是最新的数据，如果中件表有发生变化，则该缓存相关的数据就会被清空

缓存命中率比较低，最理想的情况下命中率最高13%

缓存工作

缓存相关查询

缓存相关参数

8.0之后就移除缓存模块

移除原因

SQL语句真正的执行者

1、可以降低磁盘的io次数

1.主机每次完成实事物提交，完成数据更新之前，都会把变更的数据记录在binlog日志中

2.从机开启一个IO线程去从主机的binlog日志中读取数据，记录到自己的中继日志中；

3.从机开启线程，解析中继日志的事件，并执行，来做数据主从复制

以mysql事件形式记录的是实际执行的sql语句

以MySQL事件形式记录字段前后变化的值

1.在经常当做查询条件的字段上设置索引

1.反向查询，!=,<> ,not in

2.前模糊查询

3.查询语句中在索引字段上做函数操作

4.关联字段虽然都是索引字段，如果数据类型不一致，走不了索引

5.where后面不带有效查询条件

6.建立联合索引，查询的时候不满足最左原则；

7.查询中对索引字段做运算操作

索引长度限制

索引建立字段选取

索引数量

查询服务器默认缓存区大小

SHOW VARIABLES;

SHOW STATUS；

系统变量和状态信息

key_buffer_size

table_cache

read_rnd_buffer_size

max_connections

thread_cache_size

查询相关

innerDB相关

提高搜索效率

提高读写吞吐量

CREATE TABLE `test_news` (`id` int(11) NOT NULL AUTO_INCREMENT,`title` varchar(100) DEFAULT NULL COMMENT '文章标题',`content` longtext COMMENT '文章内容',`channel` int(11) DEFAULT NULL COMMENT '文章频道',`status` int(11) DEFAULT NULL COMMENT '状态，1正常，0关闭',`create_time` datetime DEFAULT NULL COMMENT '文章发布时间',PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=513 DEFAULT CHARSET=utf8;

select* from test_news limit 10000，10；

查询每页是10条，查询低10000页的数据；这种查询完全就是没有用到索引；需要扫描到10000条数据，再开始查询

select* from test_news where id >( select id from test_news limit10000,1) limit 10；

解析

select* from test_news a join ( select id from test_news limit10000,10) b on a.id = b.id ；

解析

CREATE TABLE `test_news` (`id` int(11) NOT NULL AUTO_INCREMENT,`title` varchar(100) DEFAULT NULL COMMENT '文章标题',`content` longtext COMMENT '文章内容',`channel` int(11) DEFAULT NULL COMMENT '文章频道',`status` int(11) DEFAULT NULL COMMENT '状态，1正常，0关闭',`create_time` datetime DEFAULT NULL COMMENT '文章发布时间',PRIMARY KEY (`id`)) ENGINE=InnoDB AUTO_INCREMENT=513 DEFAULT CHARSET=utf8;

1、二进制日志格式不一样

2、字符集，函数，时区处理不一样

子主题

子主题

子主题

子主题

子主题

GET /idx_hippo_sku_statistics_index/sku_statistics_index/_search
{
 "from" : 0,
 "size" : 100,
     "query" : {
"bool" : {
  "must":[ 
      {
    "range" : {
        "salePrice" : {
          "from" : 1.9,
          "to" : 2.1,
          "include_lower": true,
           "include_upper": true
        }
       }
   }
   ,
        {
          "bool": {
              "must": {
                  "terms": {
                        "cityId": [136]
                        }
                    }
           }
        }
   
    ]
}
},
"sort": [
  {
    "salePrice": "asc"
   }
 
],
"_source": ["productName","salePrice"]
}

GET /idx_hippo_sku_statistics_index/sku_statistics_index/_search
{

 "query": {
"term": {
  "cityId": {
    "value": 136
  }
}
 },
"sort": [ { "salePrice": "asc" }

]
}

DSL语句

java代码

GET /idx_hippo_sku_statistics_index/sku_statistics_index/_search
{
"from" : 0,
 "size" : 100,
"query" : {
"bool" : {
  "must":[ 
      {
    "range" : {
        "salePrice" : {
          "from" : 1.9,
          "to" : 2.1,
          "include_lower": true,
           "include_upper": true
        }
       }
   }
   ,
        {
          "bool": {
              "must": {
                  "term": {
                        "cityId": 136
                        }
                    }
           }
        }
   
    ]
}
},
"sort": [
  {
    "salePrice": "asc"
   }
 
],
"_source": ["productName","salePrice"]
}

GET /idx_hippo_sku_statistics_index/sku_statistics_index/_search
{
"from" : 0,
"size" : 100,
"query" : {
"bool" : {
  "must":[ 
      {
    "range" : {
        "salePrice" : {
          "from" : 1.9,
          "to" : 2.1,
          "include_lower": true,
           "include_upper": true
        }
       }
   }
   ,
        {
          "bool": {
              "must": {
                  "term": {
                        "cityId": 136
                        }
                    }
           }
        }
   
    ]
}
},
"sort": [
  {
    "salePrice": "asc"
   }
 
]

}

方式1

方式2

DEMO1

DEMO2

GET /idx_hippo_shop_sku_index/shop_sku_index/_search
{
"query":{
      "match":{
                "name":"美团"
      }
}
}

GET /idx_hippo_sku_statistics_index/sku_statistics_index/_search
{

 "query": {
    "term": {
  "cityId": {
    "value": 136
     }
    }
}
}

GET /idx_hippo_shop_sku_index/shop_sku_index/1

GET index/type/_search
{
  "query": {
    "bool": {
      "must": {
        "exists": {
          "field": "字段名"
        }
      }
    }
  }
}

方式1

方式2

DSL语句

对应java代码

GET /my-index-000001/_search?from=40&size=20
{
  "query": {
    "term": {
      "user.id": "kimchy"
    }
  }
}

DSL语句

JAVA代码

为了删除旧缓存

延迟的目的：为等待数据库更新完成，2、为了让在中间其他线程在之前的查询到的旧数据写入缓存的，在最后再把缓存数据清除

子主题

子主题

子主题

大key导致占据的缓存空间过大，实际上可能这些大key并没有多少；

解决方式

某些实例分配到的槽位到，相应的得到数据量也会多

解决方式

在hash设置key的时候不要带上画括号

lua脚本的开销非常低

Lua脚本只能保证原子性，不保证事务性，当Lua脚本遇到异常时，已经执行过的逻辑是不会回滚的

这种肯定不行

这种也不行

这种也不行，如果是一个高频使用的缓存，缓存周期到了也被淘汰了

不能够完全说明这个问题；短期之内使用的比较少，但是整个周期内使用的次数比较多，这种也会被淘汰

默认淘汰策略

解决方案

1) "google"2) "yahoo"

不能被重复添加

移除 languages 中的ruby元素

移除key的所有元素

获取tool集合长度

判断key为 joe's_movies 中是否含有"bet man"

往key为page_rank集合中添加数值为10 的google.com 元素

移除指定索引区间的值

移除指定分数区间的值

获取salary集合长度

正序从小到大

整个集合从小到大排序

递减排列

获取salary集合中分数在2000到5000之间的分数

获取salary集合 peter对应的分数

排序按照分数从小到大

排序按照分数从大到小

重新设置 nosql 中指定field对应的数据

将songs 集合中的"Believe Me"元素移动到my_songs

把 source的list集合尾部元素添加到 目标元素的头部；并把值返回给客户端

上一个命令的阻塞版本

MSET date "2012.3.30" time "11:00 a.m." weather "sunny" OK

HMSET website google www.google.com yahoo www.yahoo.com OK

MGET date time weather

HMGET pet dog cat fake_pet

MSETNX rmdbs "MySQL" nosql "MongoDB" key-value-store "redis"

返回mykey对应的value的长度

返回key对应的field的个数

list集合对应的长度

没有设置存活时间

还存活 10084秒

从节点需要追赶式回复数据

切换新主节点

存在脑裂情况

写和读的副本不一样，读的副本可能还没有复制完成新数据

heapdump /tmp/dump.hprof

下载当前内存信息到某个目录下

jvm

查看当前 JVM 信息

memory

子主题

子主题

子主题

子主题

子主题

子主题

子主题

子主题

https://blog.csdn.net/u014295903/article/details/125557810

https://www.uoften.com/article/213906.html

TODO 猜测此类接口可以获取Linux系统当前cpu水位，内存消耗情况

Prometheus有具体的接口可以提供查询指标数据

对应的第三方的支持将数据导入到第三方

例如，您可以使用计数器来表示服务的请求、完成的任务或错误的数量

内存使用的最大子，最小值

需要根据基于Prometheus提供的Client Library创建自己的Exporter程序

Promthues社区官方提供了对以下编程语言的支持：Go、Java/Scala、Python、Ruby

需要独立部署的

MySQL Exporter、Redis Exporter等都是通过这种方式实现

为了能够更好的监控系统的内部运行状态，有些开源项目如Kubernetes，ETCD等直接在代码中使用了Prometheus的Client Library，提供了对Prometheus的直接支持。这种方式打破的监控的界限，让应用程序可以直接将内部的运行状态暴露给Prometheus，适合于一些需要更多自定义监控指标需求的项目。

这种方式一般都是新项目

https://blog.csdn.net/qq_25934401/article/details/82185236

https://blog.csdn.net/penngo/article/details/126982183

CAdvisor是Google开源的一款用于展示和分析容器运行状态的可视化工具

通过在主机上运行CAdvisor用户可以轻松的获取到当前主机上容器的运行统计信息，并以图表的形式向用户展示

CAdvisor默认只保存2分钟的监控数据

CAdvisor已经内置了对Prometheus的支持

用户不用再登录到服务器中即可以可视化图表的形式查看主机上所有容器的运行状态

container_cpu_load_average_10s gauge 过去10秒容器CPU的平均负载
container_cpu_usage_seconds_total counter 容器在每个CPU内核上的累积占用时间 (单位：秒)
container_cpu_system_seconds_total counter System CPU累积占用时间（单位：秒）
container_cpu_user_seconds_total counter User CPU累积占用时间（单位：秒）
container_fs_usage_bytes gauge 容器中文件系统的使用量(单位：字节)
container_fs_limit_bytes gauge 容器可以使用的文件系统总量(单位：字节)
container_fs_reads_bytes_total counter 容器累积读取数据的总量(单位：字节)
container_fs_writes_bytes_total counter 容器累积写入数据的总量(单位：字节)
container_memory_max_usage_bytes gauge 容器的最大内存使用量（单位：字节）
container_memory_usage_bytes gauge 容器当前的内存使用量（单位：字节
container_spec_memory_limit_bytes gauge 容器的内存使用量限制
machine_memory_bytes gauge 当前主机的内存总量
container_network_receive_bytes_total counter 容器网络累积接收数据总量（单位：字节）
container_network_transmit_bytes_total counter 容器网络累积传输数据总量（单位：字节）

先启动cadvisor

Prometheus配置文件中配置cadvisor的ip地址和端口

然后启动Prometheus

该引用并不是和mysql整合在一起

优点

缺点

确保Promthues服务的可用性问题

Prometheus Server之间的数据一致性问题

持久化问题(数据丢失后无法恢复)

无法进行动态的扩展

确保了数据持久化，增加了系统可扩展性

Promthues宕机后，可以快速回复

可进行数据迁移

AWS公有云平台

OpenStack的私有云平台

Kubernetes容器管理平台

接口功能

资源层

代理层

远程管理层

利用JMX创建javaBean规则

OperatingSystemMXBean

ManagementFactory.getOperatingSystemMXBean() 方式获取

RuntimeMXBean

ManagementFactory.getRuntimeMXBean()方式获取

MemoryMXBean

ManagementFactory.getMemoryMXBean()获取

ThreadMXBean

ManagementFactory.getThreadMXBean() 获取

ClassLoadingMXBean

ManagementFactory.getClassLoadingMXBean() 获取

GarbageCollectorMXBean

ManagementFactory.getGarbageCollectorMXBeans() 获取

这里获取到的是一个集合，因为垃圾收集器分为老年代和新生代两个。

1、创建需要被存入进程的对象；

2、对象必须是接口，且必须以MBean结尾

创建接口

实现接口

MBean 注册到 MBeanServer

演示

添加jvm配置

登录远程jvm

Java内置的实现监控工具 jconsole

集群指标获取

集群指标

可以对任意节点请求获取统计指标

节点指标

队列指标

GET /api/overview

GET /api/nodes/{node}

GET /api/nodes

GET /api/queues/{vhost}/{qname}

监控系统与被监控系统交织在一起

占用系统一定的开销

它只存储最近的数据（最多一天，不是几天天或几个月）

它有一个基本的用户界面

它的设计强调易用性，而不是最佳可用性

管理UI访问通过RabbitMQ权限标记系统（或JWT令牌作用域的约定）进行控制

监控系统与被监控系统分离

降低服务开销

长期存储指标

方便关联聚合对比各个相关指标

更强大和可定制的用户界面

易于分享的指标数据

更健全的访问权限

针对不同节点的数据收集更具弹性

clusterList

clusterRT

brokerStatus

getBrokerConfig

topicRoute

topicStatus

topicClusterList

topicList

statsAll

queryMsgById

queryMsgByKey

queryMsgByUniqueKey

queryMsgByOffset

printMsg

printMsgByQueue

producerConnection

consumerConnection

consumerProgress

onsumerStatus

brokerConsumeStats

checkMsgSendRT

queryCq

getNamesrvConfig

clusterAclConfigVersion

etAccessConfigSubCommand

1、系统rocketMq服务

1、通过 RocketMQ Exporter 工具从rokcetMq 上获取到相关的指标数据；

2、配置Prometheus 从RocketMQ Exporter 获取到对应的指标数据

因为kafka是java写的

实例消息生产流量（bytes/s）

实例消息消费流量（bytes/s）

实例磁盘使用率（%）-实例各节点中磁盘使用率的最大值

Topic 消息生产流量（bytes/s）

Topic 消息消费流量（bytes/s）

Group 未消费消息总数（个）

未复制的分区数

同步副本（ISR）池缩小/扩展的速率

离线分区数（仅控制器）

集群中活动控制器的数量

每秒 UncleanLeader 选举次数

特定请求（生产/提取）用时

传入/传出字节率

每秒请求数

消耗磁盘空间消耗与可用磁盘空间

页面缓存读取与磁盘读取的比率

CPU 使用率

网络字节发送/接收

JVM 执行垃圾回收进程总数

JVM 执行垃圾收集进程用时

公开了节点、连接、队列、消息速率等的RabbitMQ指标

限制

后端命令行工具

直接通过接口查询各种相关的监控信息

log-bin=mysql-bin #[必须]启用二-进制日志
server-id=100 #[必须]服务器唯一ID，如果是用于多台MySQL，ID不要重复就行
binlog-format = ROW 

<dependency>
            <groupId>com.zendesk</groupId>
            <artifactId>mysql-binlog-connector-java</artifactId>
            <version>0.27.1</version> <!--2022.09.17版的-->
        </dependency>

//为什么甚至路径都一样，还是com.github.shyiko.***，
// 因为com.zendesk这个包，里面包了个com.github.shyiko.***这玩意，我怀疑是收购关系
import com.github.shyiko.mysql.binlog.BinaryLogClient;
import com.github.shyiko.mysql.binlog.event.*;
import org.springframework.boot.ApplicationArguments;
import org.springframework.boot.ApplicationRunner;
import org.springframework.stereotype.Component;
import lombok.extern.slf4j.Slf4j;

import java.io.IOException;

//此类可以监控MySQL库数据的增删改
@Component
@Slf4j  //用于打印日志
//在SpringBoot中，提供了一个接口：ApplicationRunner。
//该接口中，只有一个run方法，他执行的时机是：spring容器启动完成之后，就会紧接着执行这个接口实现类的run方法。
public class MysqlBinLogClient implements ApplicationRunner {

    @Override
    public void run(ApplicationArguments args) throws Exception {
        //项目启动完成连接bin-log
        new Thread(() -> {
            connectMysqlBinLog();
        }).start();

    }

    /**
     * 连接mysqlBinLog
     */
    public void connectMysqlBinLog() {
        log.info("监控BinLog服务已启动");

        //自己MySQL的信息。host，port，username，password
        BinaryLogClient client = new BinaryLogClient("localhost", 3306, "root", "root");
        /**因为binlog不是以数据库为单位划分的，所以监控binglog不是监控的单个的数据库，而是整个当前所设置连接的MySQL，
         *其中任何一个库发生数据增删改，这里都能检测到，
         *所以不用设置所监控的数据库的名字(我也不知道怎么设置，没发现有包含这个形参的构造函数)
         *如果需要只监控指定的数据库，可以看后面代码，可以获取到当前发生变更的数据库名称。可以根据名称来决定是否监控
         **/

        client.setServerId(100); //和自己之前设置的server-id保持一致，但是我不知道为什么不一致也能成功

//下面直接照抄就行
        client.registerEventListener(event -> {
            EventData data = event.getData();
            if (data instanceof TableMapEventData) {
                //只要连接的MySQL发生的增删改的操作，则都会进入这里，无论哪个数据库

                TableMapEventData tableMapEventData = (TableMapEventData) data;

                //可以通过转成TableMapEventData类实例的tableMapEventData来获取当前发生变更的数据库
                System.out.println("发生变更的数据库："+tableMapEventData.getDatabase());

                System.out.print("TableID:");
                //表ID
                System.out.println(tableMapEventData.getTableId());
                System.out.print("TableName:");
                //表名字
                System.out.println(tableMapEventData.getTable());
            }
            //表数据发生修改时触发
            if (data instanceof UpdateRowsEventData) {
                System.out.println("Update:");
                System.out.println(data.toString());
                //表数据发生插入时触发
            } else if (data instanceof WriteRowsEventData) {
                System.out.println("Insert:");
                System.out.println(data.toString());
                //表数据发生删除后触发
            } else if (data instanceof DeleteRowsEventData) {
                System.out.println("Delete:");
                System.out.println(data.toString());
            }
        });

        try {
            client.connect();
        } catch (IOException e) {
            e.printStackTrace();
        }

    }
}

数据来源

具体指标

方式

具体指标

参考文档

基于云的远程监控

查询分析可视化

支持 MySQL 集群监控

实时健康状态上报、可用性监控

易于配置

监控脚本来利用Redis提供的MONITOR命令从被监控Redis实例中获取数据并存储到Redis的监控实例中来做数据分析

RedisLive以可视化的方式展示了Redis实例中的数据，分析查询模式和峰值

执行 info clients 命令获取 connected_clients 就是客户端连接数

此命令可以查询吞吐量相关的监控项

总执行命令数量

当前 Redis 实例的 OPS

网络总入量

网络总出量

每秒输入量，单位是kb/s

每秒输出量，单位是kb/s

used_memory

maxmemory

计算方式：used_memory_rss/used_memory

大于 1 表示有内存碎片，越大表示越多；小于 1 表示正在使用虚拟内存，虚拟内存其实就是硬盘，性能会下降很多。一般内存碎片率在 1 - 1.5 之间比较健康。

相关参数均为执行完 info Persistence 的结果

rdb_last_bgsave_status

rdb_last_bgsave_time_sec

aof_current_size

什么是大key

监控方式

监控方式

执行时间超过了多久，会被记录到慢查询日志中

慢日志的长度

slowlog get

slowlog get 1

集群状态

hash槽状态

节点数量

cluster info 命令中可以获取集群的状态

keyspace_hits 表示 Redis 请求键被命中的次数

keyspace_misses 表示 Redis 请求键未被命中的次数

命中率越低，导致越多的缓存穿透，对mysql容易造成影响

1.数据量大了，也会造成性能问题；

2.zset集合中的数据越来越多的时候，zset的性能也会越来越低

获取数据库自增的主键作为全局ID

实现简单

id是递增

数值类型查询速度快

如果数据是单节点，无法完全保证数据的高可以用

给几台数据库服务器自增时候设置相应的步长（比如说，自增3，自增4），获取到自增id

解决单节点，并不能高可用问题

不利于后续扩容

从数据库批量获取自增ID

批量减少数据库压力

通过RedisClient对象获取到RedissionLock对象

通过RedissionLock对象进行加锁

分支主题

未设置，程序异常，导致当前代码永远死锁

防止获取到锁的程序，由于某种原因一直不释放锁，阻塞后续线程执行

防止sentx命令执行完成，再去执行设置超时时间中间，reids宕机；

获取不到锁的线程，需要让这些线程做获取的锁的等待从而可以执行锁中间的代码，而不是直接返回到客户端

死循环不断的尝试获取锁操作，获取到锁操作后，跳出死循环；

锁失效后，其他线程可以直接获取到锁对象，两个线程同时执行锁中间的代码，无法保证串行执行；

需要给锁有效期续命

当获取的key对应的库存数据为0时候，需要释放当前锁，且需要再次获取其他库存不为0的锁；

运营后台需要针对线下商品的批量操作，一个商品可以绑定200-300个门店，批量100个商品就会有2W-3W条数据更新

2W-3W条数据，使得程序响应过慢，运用以为操作失败，然后接着继续狂点，导致服务器内存溢出宕机；

方式1

以鸡蛋，大白菜，食盐等商品做1毛钱秒杀活动，达到线上引流目的

1、初始化分段锁信息

2、用原子类的Long记录请求请求数量

3、对请求数量按照锁的个数取模，以此来确定需要访问具体的是哪个子锁

4、尝试sentx操作，key为子锁key,为第三步中获取的value为库存

5、获取到锁之后，执行业务代码，然后在最后更新hash表中的库存数据，也更新当前子锁对应库存数据

6、最后解锁

7、未获取到锁的线程，在做死循环自旋的时候，每次sentx操作之前都是需要获取hash表中库存数据；确保获取的库存数据是最新数据

Try

Confirm

Cancel

资源预留阶段

事物提交阶段/事物回滚阶段

需要标记Try，confirm，cancel方法

备注：主要是这些数据库都遵守2PC协议

第一阶段每个事物完成预提交并通知把结果告诉事物协调器；事物协调器等所有分支事物都操作完成，预提交之后；第二阶段协调器通知每个事物进行逐步的提交或者是逐步的回滚操作；

准备阶段

提交阶段

使用方式

使用场景

流程比较长且只需要保证事物最终一致性的长事物解决方案

事物的参与者是其他公司的服务

优点

缺点

最大努力通知

消息队列通知

优点

缺点

特点

方案差别

具体实现方案

将长事物拆分成多个本地事物，由Saga事物协调器协调，正常结束就正常完成，如果某个步骤失败，则根据相反顺序以此调用补偿操作；

1、协调者向所有参与者发送事物提交消息；

2、参与者提交事物，释放事物锁定期间的资源；

3、参与者向协调者反馈事物执行成功消息

4、协调者收到各个参与者执行成功的消息，事物就成功

1、协调者向所有参与者发送事物回滚消息；

2、参与者做回滚操作，释放事物锁定期间的资源；

3、参与者向协调者反馈事物执行成功消息

4、协调者收到各个参与者执行成功的消息，事物就中断

备注：如果协调者在接收事务请求时出现故障或者不可用，协调者将直接中止事务

备注：如果参与者都同意后会向协调者回复yes消息并进入准备状态，如果参与者获取资源失败或者出现不可用会回复no中止事务

高并发的情况下， 悲观锁比乐观锁效率高

相应速度，冲突频率，重试代价

乐观锁基于重试的代价太高了

令牌桶

漏桶

1、二进制日志格式不一样

2、字符集，函数，时区处理不一样

常量池

连接池

线程池

单例设计模式

字符串操作避免内存泄露

切割查找选择最快方式

根据当前业务查询多还是修改多，合理选用对应的容器

局部变量的容器，选择对应的操作快速的线程不安全的容器

容器的初始化长度可以，根据预估的数据量

GC不会回收静态方法占用的元空间数据

对象需要开辟堆内存，基本类型需不要堆内存

时间复杂度，空间复杂度

锁对象使用合理

乐观锁

1、合理设置索引

2、合理的提前生成统计数据

3、连接池优化

4、减少关联查询

1、合理分库分表

2、合理冗余字段

内存更大， 磁盘更大， cpu核数更多，运算速度更快

数据库日志刷盘策略

缓冲池大小

统一给这些io设置线程池，不让他们占用过多的系统资源

cpu消耗过高的是同一个线程

cpu消耗过高的是不同的线程

专门用来分析dump文件的

生产者自己异常，导致消费发送失败，生产者会有重试机制，重新发送消息

消息确认等级

消息确认相应机制

消息重投机制，消息投递失败，会再次投递

发送端把消息发送个服务端，服务端接收到消息并且把消息持持久化到磁盘就会给发送端一个异步的confirm应答

发送端开启一个事物，再推送消息，如果投递失败；进行事物回滚，然后重新发送消息；如果服务端收到消息，发送端就提交事务。

参数设置：min.insync.replica

参数设置：unclean.leader.election.enable=false 本身默认就是flase

将异步持久化到磁盘，修改成同步持久化到磁盘

RocketMq消息本身默认的持久化盘刷机制是异步刷盘

确保主机挂了，从机上还有消息备份数据

1、服务端收到生产者发送过来的消息，会做消息的持久化

2、当服务宕机后， 会从磁盘当中读取相应的消息，最大程度上保证消息不在服务节点上丢失

1.消费者在处理消息的时候出现异常了，那么这条消息就是没有被正常的消费；如果不采取措施，那么这个消息就会丢失

ack机制

生产者自己异常，导致消费发送失败，生产者会有重试机制，重新发送消息

消息确认等级

消息确认相应机制

消息重投机制，消息投递失败，会再次投递

发送端把消息发送个服务端，服务端接收到消息并且把消息持持久化到磁盘就会给发送端一个异步的confirm应答

发送端开启一个事物，再推送消息，如果投递失败；进行事物回滚，然后重新发送消息；如果服务端收到消息，发送端就提交事务。

参数设置：min.insync.replica

参数设置：unclean.leader.election.enable=false 本身默认就是flase

将异步持久化到磁盘，修改成同步持久化到磁盘

RocketMq消息本身默认的持久化盘刷机制是异步刷盘

确保主机挂了，从机上还有消息备份数据

1、服务端收到生产者发送过来的消息，会做消息的持久化

2、当服务宕机后， 会从磁盘当中读取相应的消息，最大程度上保证消息不在服务节点上丢失

1.消费者在处理消息的时候出现异常了，那么这条消息就是没有被正常的消费；如果不采取措施，那么这个消息就会丢失

ack机制

1.数据量大了，也会造成性能问题；

2.zset集合中的数据越来越多的时候，zset的性能也会越来越低

获取数据库自增的主键作为全局ID

实现简单

id是递增

数值类型查询速度快

如果数据是单节点，无法完全保证数据的高可以用

给几台数据库服务器自增时候设置相应的步长（比如说，自增3，自增4），获取到自增id

解决单节点，并不能高可用问题

不利于后续扩容

从数据库批量获取自增ID

批量减少数据库压力

通过RedisClient对象获取到RedissionLock对象

通过RedissionLock对象进行加锁

分支主题

未设置，程序异常，导致当前代码永远死锁

防止获取到锁的程序，由于某种原因一直不释放锁，阻塞后续线程执行

防止sentx命令执行完成，再去执行设置超时时间中间，reids宕机；

获取不到锁的线程，需要让这些线程做获取的锁的等待从而可以执行锁中间的代码，而不是直接返回到客户端

死循环不断的尝试获取锁操作，获取到锁操作后，跳出死循环；

锁失效后，其他线程可以直接获取到锁对象，两个线程同时执行锁中间的代码，无法保证串行执行；

需要给锁有效期续命

当获取的key对应的库存数据为0时候，需要释放当前锁，且需要再次获取其他库存不为0的锁；

运营后台需要针对线下商品的批量操作，一个商品可以绑定200-300个门店，批量100个商品就会有2W-3W条数据更新

2W-3W条数据，使得程序响应过慢，运用以为操作失败，然后接着继续狂点，导致服务器内存溢出宕机；

方式1

以鸡蛋，大白菜，食盐等商品做1毛钱秒杀活动，达到线上引流目的

1、初始化分段锁信息

2、用原子类的Long记录请求请求数量

3、对请求数量按照锁的个数取模，以此来确定需要访问具体的是哪个子锁

4、尝试sentx操作，key为子锁key,为第三步中获取的value为库存

5、获取到锁之后，执行业务代码，然后在最后更新hash表中的库存数据，也更新当前子锁对应库存数据

6、最后解锁

7、未获取到锁的线程，在做死循环自旋的时候，每次sentx操作之前都是需要获取hash表中库存数据；确保获取的库存数据是最新数据

Try

Confirm

Cancel

资源预留阶段

事物提交阶段/事物回滚阶段

需要标记Try，confirm，cancel方法

备注：主要是这些数据库都遵守2PC协议

第一阶段每个事物完成预提交并通知把结果告诉事物协调器；事物协调器等所有分支事物都操作完成，预提交之后；第二阶段协调器通知每个事物进行逐步的提交或者是逐步的回滚操作；

准备阶段

提交阶段

使用方式

使用场景

流程比较长且只需要保证事物最终一致性的长事物解决方案

事物的参与者是其他公司的服务

优点

缺点

最大努力通知

消息队列通知

优点

缺点

特点

方案差别

具体实现方案

将长事物拆分成多个本地事物，由Saga事物协调器协调，正常结束就正常完成，如果某个步骤失败，则根据相反顺序以此调用补偿操作；

1、协调者向所有参与者发送事物提交消息；

2、参与者提交事物，释放事物锁定期间的资源；

3、参与者向协调者反馈事物执行成功消息

4、协调者收到各个参与者执行成功的消息，事物就成功

1、协调者向所有参与者发送事物回滚消息；

2、参与者做回滚操作，释放事物锁定期间的资源；

3、参与者向协调者反馈事物执行成功消息

4、协调者收到各个参与者执行成功的消息，事物就中断

备注：如果协调者在接收事务请求时出现故障或者不可用，协调者将直接中止事务

备注：如果参与者都同意后会向协调者回复yes消息并进入准备状态，如果参与者获取资源失败或者出现不可用会回复no中止事务

高并发的情况下， 悲观锁比乐观锁效率高

相应速度，冲突频率，重试代价

乐观锁基于重试的代价太高了

令牌桶

漏桶

1、二进制日志格式不一样

2、字符集，函数，时区处理不一样

请求方法

路径

协议版本

回车符+换行符

回车符+换行符

协议版本

状态码

状态码描述符

回车符+换行符

回车符+换行符

无锁

偏向锁

轻量级锁，重量级锁

Gc标记

三色标记算法是一种垃圾回收的标记算法

减少jvm 的STW(Stop The World)，从而达到清除JVM内存垃圾的目的

JVM中的CMS、G1垃圾回收器 所使用垃圾回收算法即为三色标记法。

黑色：代表该对象以及该对象下的属性全部被标记过了。（程序需要用到的对象，不应该被回收）

灰色：对象被标记了，但是该对象下的属性未被完全标记。（需要在该对象中寻找垃圾）

白色：对象未被标记（需要被清除的垃圾）

并发标记的时候，存在漏标的情况

1.标记-清除的效率都不高

2.清除会造成很多内存碎片，有可能导致二级gc;

每个region 区域的大小都是2的N次幂；即1Mb,2Mb，4MB,

region 区域大小在jvm运行期间都是不会被改变

每个region区域的大小都是相等的

每一个region区域只会属于Eden， Survivo，old其中的一种

Eden， Survivo，老年代的区域并不是连续；

新增一种新的内存区域，Humongous内存区域，超过0.5个region对象就会被放Humongous区域

固定为2MB

用于存放256KB以下的小对象

固定位32MB

用于存放256KB以上，4MB以下的对象

大小不固定，但必须是2MB的2次幂的大小

只会存放大于或者等于4MB的大对象，每一个大页面，只会存储一个大对象

以前在64位的计算上，内存控制器没有整合进cpu,对内存的访问都必须要通过北桥芯片来控制，任何cpu对内存的访问速度都是一致。

示意图

cpu都整合到同一个芯片上，各个cpu对于内存的访问会出现争抢，会导致内存访问瓶颈；为了解决这个，将内存和cpu集成在一个单元上，这个就是非统一内存访问

示意图

标记阶段

转移阶段

估算当前的堆内存分配速率，速度估计越快，GC来的越早，速度估算越慢，GC来的越迟

定 GC 发生的间隔，以秒为单位触发 GC

Stw阶段，GC线程的数量

并发阶段，cpu的数量