java8系列专栏之字符串
前言
写这篇文章的目的是为了记录一下学习笔记,其次为了能够在复习的时候快速掌握相关知识。本篇记录java8系列专栏之字符串
正文
StringJoiner
详解
拼接字符串
用法
1 | //不指定前缀和后缀 |
String.join
详解
拼接字符串,缺点是无法指定前缀和后缀
用法
1 | List<String> list = Arrays.asList("a","b","c"); |
写这篇文章的目的是为了记录一下学习笔记,其次为了能够在复习的时候快速掌握相关知识。本篇记录java8系列专栏之字符串
拼接字符串
1 | //不指定前缀和后缀 |
拼接字符串,缺点是无法指定前缀和后缀
1 | List<String> list = Arrays.asList("a","b","c"); |
写这篇文章的目的是为了记录一下学习笔记,其次为了能够在复习的时候快速掌握相关知识。本篇记录java8系列专栏之Date Time API
可以取代System.currentTimeMillis()
,时区敏感,带有时区信息
1 | Clock clock = Clock.systemDefaultZone(); |
新的时区类 java.time.ZoneId
是原有的 java.util.TimeZone
类的替代品。 ZoneId对象可以通过 ZoneId.of()
方法创建,也可以通过 ZoneId.systemDefault()
获取系统默认时区。
1 | System.out.println(ZoneId.getAvailableZoneIds()); |
有了 ZoneId,我们就可以将一个 LocalDate、LocalTime 或 LocalDateTime 对象转化为 ZonedDateTime 对象
1 | LocalDateTime localDateTime = LocalDateTime.now(); |
ZonedDateTime 对象由两部分构成,LocalDateTime 和 ZoneId,其中 2018-03-03T15:26:56.147 部分为 LocalDateTime,+08:00[Asia/Shanghai] 部分为ZoneId。
LocalTime类是Java 8中日期时间功能里表示一整天中某个时间点的类,它的时间是无时区属性的(早上10点等等)
1 | LocalTime now1 = LocalTime.now(zone1); |
LocalDate类是Java 8中日期时间功能里表示一个本地日期的类,它的日期是无时区属性的。 可以用来表示生日、节假日期等等。这个类用于表示一个确切的日期,而不是这个日期所在的时间
1 | LocalDate today = LocalDate.now(); |
LocalDateTime类是Java 8中日期时间功能里,用于表示当地的日期与时间的类,它的值是无时区属性的。你可以将其视为Java 8中LocalDate与LocalTime两个类的结合。
1 | LocalDateTime sylvester = LocalDateTime.of(2014, Month.DECEMBER, 31, 23, 59, 59); |
ZonedDateTime类是Java 8中日期时间功能里,用于表示带时区的日期与时间信息的类。可以用于表示一个真实事件的开始时间,如某火箭升空时间等等。
1 | ZonedDateTime dateTime = ZonedDateTime.now(); |
一个Duration对象表示两个Instant间的一段时间
1 | Instant first = Instant.now(); |
DateTimeFormatter类是Java 8中日期时间功能里,线程安全。用于解析和格式化日期时间的类
。类中包含如下预定义的实例:
1 | BASIC_ISO_DATE |
1 | DateTimeFormatter formatter = DateTimeFormatter.ISO_DATE_TIME; |
[toc]
本文问题参考朱小厮的博客。写这个只是为了检验自己最近的学习成果,因为是自己的理解,如果问题,欢迎指出。废话少说,上干货。
总结下来就几个字:异步处理、日常系统解耦、削峰、提速、广播
如果再说具体一点例如:消息,网站活动追踪,监测指标,日志聚合,流处理,事件采集,提交日志等
ISR:In-Sync Replicas 副本同步队列
AR:Assigned Replicas 所有副本
ISR是由leader维护,follower从leader同步数据有一些延迟(包括延迟时间replica.lag.time.max.ms和延迟条数replica.lag.max.messages两个维度, 当前最新的版本0.10.x中只支持replica.lag.time.max.ms这个维度),任意一个超过阈值都会把follower剔除出ISR, 存入OSR(Outof-Sync Replicas)列表,新加入的follower也会先存放在OSR中。AR=ISR+OSR。
HW:High Watermark 高水位,取一个partition对应的ISR中最小的LEO作为HW,consumer最多只能消费到HW所在的位置上一条信息。
LEO:LogEndOffset 当前日志文件中下一条待写信息的offset
HW/LEO这两个都是指最后一条的下一条的位置而不是指最后一条的位置。
LSO:Last Stable Offset 对未完成的事务而言,LSO 的值等于事务中第一条消息的位置(firstUnstableOffset),对已完成的事务而言,它的值同 HW 相同
LW:Low Watermark 低水位, 代表 AR 集合中最小的 logStartOffset 值
kafka每个partition中的消息在写入时都是有序的,消费时,每个partition只能被每一个group中的一个消费者消费,保证了消费时也是有序的。
整个topic不保证有序。如果为了保证topic整个有序,那么将partition调整为1.
拦截器->序列化器->分区器
2个,主线程和Sender线程。主线程负责创建消息,然后通过分区器、序列化器、拦截器作用之后缓存到累加器RecordAccumulator中。Sender线程负责将RecordAccumulator中消息发送到kafka中.
不正确,通过自定义分区分配策略,可以将一个consumer指定消费所有partition。
offset+1
消费者消费后没有commit offset(程序崩溃/强行kill/消费耗时/自动提交偏移情况下unscrible)
消费者没有处理完消息 提交offset(自动提交偏移 未处理情况下程序异常结束)
1.在每个线程中新建一个KafkaConsumer
2.单线程创建KafkaConsumer,多个处理线程处理消息(难点在于是否要考虑消息顺序性,offset的提交方式)
消费者从属与消费组,消费偏移以消费组为单位。每个消费组可以独立消费主题的所有数据,同一消费组内消费者共同消费主题数据,每个分区只能被同一消费组内一个消费者消费。
创建:在zk上/brokers/topics/下节点 kafkabroker会监听节点变化创建主题
删除:调用脚本删除topic会在zk上将topic设置待删除标志,kafka后台有定时的线程会扫描所有需要删除的topic进行删除
可以
不可以
根据集群的机器数量和需要的吞吐量来决定适合的分区数
__consumer_offsets 以下划线开头,保存消费组的偏移
优先副本 会是默认的leader副本 发生leader变化时重选举会优先选择优先副本作为leader
创建主题时
如果不手动指定分配方式 有两种分配方式
消费组内分配
每个partition一个文件夹,包含四类文件.index .log .timeindex leader-epoch-checkpoint
.index .log .timeindex 三个文件成对出现 前缀为上一个segment的最后一个消息的偏移 log文件中保存了所有的消息 index文件中保存了稀疏的相对偏移的索引 timeindex保存的则是时间索引
leader-epoch-checkpoint中保存了每一任leader开始写入消息时的offset 会定时更新
follower被选为leader时会根据这个确定哪些消息可用
如上
1.通过文件名前缀数字x找到该绝对offset 对应消息所在文件
2.offset-x为在文件中的相对偏移
3.通过index文件中记录的索引找到最近的消息的位置
4.从最近位置开始逐条寻找
原理同上 但是时间的因为消息体中不带有时间戳 所以不精确
kafka留存策略包括 删除和压缩两种
删除: 根据时间和大小两个方式进行删除 大小是整个partition日志文件的大小
超过的会从老到新依次删除 时间指日志文件中的最大时间戳而非文件的最后修改时间
压缩: 相同key的value只保存一个 压缩过的是clean 未压缩的dirty 压缩之后的偏移量不连续 未压缩时连续
pid+序号实现,单个producer内幂等
生产者关注MessagesInPerSec、BytesOutPerSec、BytesInPerSec 消费者关注消费延迟Lag
零拷贝,页缓存,顺序写
吞吐量高,大数据消息系统唯一选择。
confluent全家桶(connect/kafka stream/ksql/center/rest proxy等),开源监控管理工具kafka-manager,kmanager等
为什么会有这个需求?
kafka consumer 消费会存在延迟情况,我们需要查看消息堆积情况,就是所谓的消息Lag。目前是市面上也有相应的监控工具KafkaOffsetMonitor,我们自己也写了一套监控KafkaCenter。但是随着kafka版本的升级,消费方式也发生了很大的变化,因此,我们需要重构一下kafka offset监控。
在计算Lag之前先普及几个基本常识
LEO(LogEndOffset): 这里说的和官网说的LEO有点区别,主要是指堆consumer可见的offset.即HW(High Watermark)
CURRENT-OFFSET: consumer消费到的具体位移
知道以上信息后,可知Lag=LEO-CURRENT-OFFSET
。计算出来的值即为消费延迟情况。
这里说的官方查看方式是在官网文档中提到的,使用官方包里提供的bin/kafka-consumer-groups.sh
最新版的工具只能获取到通过broker消费的情况
1 | $ bin/kafka-consumer-groups.sh --describe --bootstrap-server 192.168.0.101:8092 --group test |
使用程序查询方式,有什么好处,可以实现自己的offset监控,可以无缝接入任何平台系统。
既然是用程序实现,那么做个更高级的需求,++根据topic获取不同消费组的消费情况++。
先定义两个实体
TopicConsumerGroupState
1 | public class TopicConsumerGroupState { |
PartitionAssignmentState
1 | public class PartitionAssignmentState { |
引入最新版依赖,使用KafkaAdminClient获取1,2处信息
1 | <dependency> |
1 | public Set<String> listConsumerGroups(String topic) |
使用describeConsumerGroup获取的消费情况,其中包含有members和无members情况。正常订阅消费是可以获取到members,但是通过制定patition消费拿不到members.
1 | /** |
1 | public Map<TopicPartition, Long> consumerOffset (String gorupName,String topicName) { |
1 | private List<TopicConsumerGroupState> getBrokerConsumerOffsets(String clusterID, String topic) { |
引入两个依赖,主要是为了读取zookeeper节点上的数据
1 | <dependency> |
1 | public Set<String> listTopicGroups(String topic) { |
1 | public Map<String, Map<String, String>> getZKConsumerOffsets(String groupId, String topic) { |
略
4. 步骤4
1 | private List<TopicConsumerGroupState> getZKConsumerOffsets(String topic) { |
前端页面权限在日常开发中,主要有以下:
登录授权,用户没有登录只能访问登录页面,如果处于登录状态则跳转到当前用户的默认首页;
路由授权,当前登录用户的角色,如果对一个 URL 没有权限访问,则跳转到 403 页面;
数据授权,当访问一个没有权限的 API,则跳转到 403 页面;
操作授权,当页面中某个按钮或者区域没有权限访问则在页面中隐藏
本文主要针对ICE飞冰模板,介绍下如何开发权限管理,主要是使用,不涉及任何架构设计及原理,关于原理可以参考源码分析,或者参考本文参考链接。
首先先安装依赖,因为飞冰权限是使用Authorized 权限组件实现了基本的权限管理方案。
1 | npm install antd --save |
因为ant-design-pro依赖antd,因此需要首先安装antd
在开始之前需要新增两个util,一个设置登录权限,一个为了重新渲染权限
authority.js
1 | // use localStorage to store the authority info, which might be sent from server in actual project. |
Authorized.js
1 | import RenderAuthorized from 'ant-design-pro/lib/Authorized'; |
看过很多文档,经过精心整理对比,觉得以下几个对我来说最有帮助,在此记录一下,分享给更多的人。
props 用来传递数据,state 用来存储组件内部的状态和数据。props 是只读的,state 当前组件 state 的值可以作为 props 传递给下层组件
React 组件的变化是基于状态的
通过setState更改状态的内容
1 | this.setState({ |
问题背景:手动触发事件,更改state中数据
1 | mergeFilter = ()=> { |
1 | <EuiSwitch |
1 | constructor(props) { |
这里的传值是组件化传值,属性在组件中是可以自定义的。
在父组件中添加子组件后,可以添加任意属性,如下的dialogObj:
1 | <DetailDialog dialogObj={dialogObj} } /> |
对于在子组件中可以在构造方法中获取该属性
1 | constructor(props) { |
对于父组件该属性发生变化,如何更新呢,这里利用生命周期中的componentWillReceiveProps,这样即可获悉到属性的变化。
1 | // 接受父类props改变,修改子类中的属性 |
在开发的场景中,经常存在需要在父组件中触发子组件方法
通过属性传值能解决业务问题的,优先建议使用属性传值解决。如果不能解决,可以考虑使用ref解决调用问题
例如:
1 | <SimpleFormDialog ref="getDialog"> |
在开发的场景中,经常存在需要在子组件中触发父组件方法
在添加子组件的时候使用如下方式
1 | <DetailDialog hideDetailDialog={this.hideDetailDialog} /> |
类似于属性传递,方法也可以传递的,这样在子组件中方法调用一下即可:
1 | hideDetailDialog = () => { |
略,详见redux
KSQL是Apache Kafka的流式SQL引擎,让你可以SQL语方式句执行流处理任务。KSQL降低了数据流处理这个领域的准入门槛,为使用Kafka处理数据提供了一种简单的、完全交互的SQL界面。你不再需要用Java或Python之类的编程语言编写代码了!KSQL具有这些特点:开源(采用Apache 2.0许可证)、分布式、可扩展、可靠、实时。它支持众多功能强大的数据流处理操作,包括聚合、连接、加窗(windowing)和sessionization(捕获单一访问者的网站会话时间范围内所有的点击流事件)等等。
Apache Kafka是为数据管道的流行选择。 KSQL使得在管道中转换数据变得简单,准备好消息以便在另一个系统中干净地着陆。
通过快速构建实时仪表板,生成指标以及创建自定义警报和消息,跟踪,了解和管理基础架构,应用程序和数据源。
在Kafka中导航并浏览您的数据。
通过毫秒级延迟识别模式并发现实时数据中的异常,使您能够正确地表现出异常事件并分别处理欺诈活动。
为用户创建数据驱动的实时体验和洞察力。
理解并提供传感器数据的方式和位置。
通过各种渠道全面了解客户的每一次互动,实时不断地整合新信息。
KSQL服务器运行执行KSQL查询的引擎。这包括处理,读取和写入目标Kafka集群的数据。 KSQL服务器构成KSQL集群,可以在容器,虚拟机和裸机中运行。您可以在实时操作期间向/从同一KSQL群集添加和删除服务器,以根据需要弹性扩展KSQL的处理能力。您可以部署不同的KSQL集群以实现工作负载隔离。
你可以使用KSQL命令行界面(CLI)以交互方式编写KSQL查询。 KSQL CLI充当KSQL服务器的客户端。对于生产方案,您还可以将KSQL服务器配置为以非交互式“无头”配置运行,从而阻止KSQL CLI访问。
KSQL服务器,客户端,查询和应用程序在Kafka brokers之外,在单独的JVM实例中运行,或者在完全独立的集群中运行。
流是结构化数据的无界序列。例如,我们可以进行一系列金融交易,例如“Alice向Bob发送了100美元,然后Charlie向Bob发送了50美元”。流中的事实是不可变的,这意味着可以将新事实插入到流中,但是现有事实永远不会被更新或删除。可以从Kafka主题创建流,也可以从现有流派生流。流的基础数据在topic中持久存储(持久化)
表是流或其他表的视图,表示不断变化的事实的集合。例如,我们可以有一个表格,其中包含最新的财务信息,例如“Bob的当前账户余额为150美元”。它相当于传统的数据库表,但通过流式语义(如窗口)进行了丰富。表中的事实是可变的,这意味着可以将新事实插入表中,并且可以更新或删除现有事实。可以从Kafka主题创建表,也可以从现有流和表派生表。在这两种情况下,表的基础数据都在topic中持久存储(持久化)。
在KSQL 5.0及更高版本中,您可以使用CREATE STREAM和CREATE TABLE语句中的STRUCT类型以Avro和JSON格式读取嵌套数据。
CREATE STREAM/TABLE (from a topic)
CREATE STREAM/TABLE AS SELECT (from existing streams/tables)
SELECT (non-persistent query)
例如
1 | CREATE STREAM orders ( |
目前confluent KSQL支持两种方式,一种是ksql-cli,一种是rest
这里我仅演示使用docker方式
1 | sudo docker run -it --rm confluentinc/cp-ksql-cli:5.1.2 http://192.168.0.11:8088 |
1 | curl --request POST \ |
rest主要有两个接口1.ksql2.query,对于一般查询语句可以使用query接口。其他的命令操作一般使用ksql接口。
命令 | 描述 |
---|---|
CREATE STREAM | |
CREATE TABLE | |
CREATE STREAM AS SELECT | |
CREATE TABLE AS SELECT | |
INSERT INTO | |
DESCRIBE | |
DESCRIBE FUNCTION | |
EXPLAIN | |
DROP STREAM [IF EXISTS] [DELETE TOPIC]; | |
DROP TABLE [IF EXISTS] [DELETE TOPIC]; | |
SELECT | 在select下支持更多sql语法,这里不一一列出 |
SHOW FUNCTIONS | |
SHOW TOPICS | |
SHOW STREAMS | |
SHOW TABLES | |
SHOW QUERIES | 列出持久化查询 |
DDL包括以下:
DML包括以下:
KSQL支持时间窗口操作,以下是目前支持的几种类型:
Window type | 行为 | 描述 |
---|---|---|
Hopping Window | 基于时间 | 固定持续时间,重叠的窗口 |
Tumbling Window | 基于时间 | 固定持续时间,非重叠,无间隙窗口 |
Session Window | 基于session | 动态大小,不重叠,数据驱动的窗口 |
这里我演示一个反爬虫检测的案例, 根据EC_bot_detection的数据抓取一分钟内超过限制的IP.
根据消费kafka中EC_bot_detection.replica数据,定义不同字段的数据类型,按照该数据定义语句如下
1 | CREATE STREAM ec_bot_detection (action VARCHAR, nvtc VARCHAR,nid VARCHAR,ip VARCHAR,msg VARCHAR,level VARCHAR,verb VARCHAR,url VARCHAR,purl VARCHAR,ua VARCHAR,valid INTEGER,nNvtc VARCHAR,nNid VARCHAR,cip VARCHAR,sip VARCHAR,xpost VARCHAR,time VARCHAR,id VARCHAR,xprotocol VARCHAR,xhost VARCHAR,xport VARCHAR,xpath VARCHAR,xquery VARCHAR,xpathalias VARCHAR,xkey VARCHAR,importance INTEGER,xpprotocol VARCHAR,xphost VARCHAR,xpport VARCHAR,xppath VARCHAR,xpquery VARCHAR,org VARCHAR,cyc VARCHAR,isp VARCHAR,cycName VARCHAR,region VARCHAR,city VARCHAR,geoLocation VARCHAR,zipcode VARCHAR) WITH (VALUE_FORMAT = 'JSON',KAFKA_TOPIC = 'EC_bot_detection.replica'); |
查询语句
bot_detection_1min
1 | SELECT ip,org,cyc,count(1) as ccount FROM EC_BOT_DETECTION WINDOW TUMBLING (SIZE 60 SECONDS) WHERE xhost not like '%.tw' and level='-1' AND importance=1 AND (msg<>'W' OR msg is null) and action like'crawler%' AND ip NOT LIKE '127.0.0.1' AND ip NOT LIKE '172.16.%' AND ip <> '' AND xpathalias !='LandingpageOverviewcontent4mobile' AND xpathalias !='CommonCommonrecaptchavalidate' GROUP BY ip,org,cyc HAVING count(1)>300; |
为了将查询结果存储到kafka中,我们可以使用
CREATE TABLE TableName as SELECT …
1 | CREATE TABLE bot_detection_1min as SELECT ip,org,cyc,count(1) as ccount FROM EC_BOT_DETECTION WINDOW TUMBLING (SIZE 60 SECONDS) WHERE xhost not like '%.tw' and level='-1' AND importance=1 AND (msg<>'W' OR msg is null) and action like'crawler%' AND ip NOT LIKE '127.0.0.1' AND ip NOT LIKE '172.16.%' AND ip <> '' AND xpathalias !='LandingpageOverviewcontent4mobile' AND xpathalias !='CommonCommonrecaptchavalidate' GROUP BY ip,org,cyc HAVING count(1)>300; |
目前官方提供的函数不足以满足业务场景的需求情况下,我们可以扩展自定义函数udf/udaf
用户自定义函数,可以实现针对column操作的函数,例如以下案例,实现字母转大写
1 | @UdfDescription(name = "upper", description = "字符串转大写") |
用户自定义聚合函数,以下是聚合求百分比函数demo
1 | @UdafDescription(name = "percent", description = "聚合求百分比") |
通过两周ksql的使用,现发现有如下问题不能满足
1 | select distinct ip from #table; |
1 | select ip from (select * from table); |
1 | sum(case when nvtc='' then 1 else 0 end) |
1 | xpathalias not in ('Landingpage','Wishlist','CommonMessagepage','Common') |
最近开源了一个redis内存分析一站式平台RCT,想让更多的人指定我们这个项目,正好看到同类几个开源项目,就想着爬取关注的用户,给他们发邮件,推广一下我们的项目。
因为本地linux机器安装的python版本为2.7.0,因此使用python2语法
1 | $ pip install PyGithub |
1 | from github import Github |
1 | python crawer.py |
在运行过程中发现关于用户数据是输出的时候才再去github查询的,这也就意味着,及时stargazers已经获取,还会继续去调用github api。可能会存在网络问题。
目前我们EC Bigdata team 运维公司 4个 Redis 集群,300+ Redis 实例,500G+ 的内存数据,我们想要分析业务是否有误用,以提高资源利用率。伴随着业务team的广泛使用,近期数据增 长比较快,我们紧迫需要一个工具分析一下各种业务存储的数据有多大,是否存入僵死数据浪费资源;同时E4 WWW redis 集群有业务方反馈近期有比较明显的慢查询发生,所以我们需要针对 slow log 和存入的常用数据类型Hash,List,Set分析,是否有big key引起慢查询,是否有team存在超大的 big key和不合理设置ttl的情况
那有没有什么办法让我们安全高效的看到 Redis 内存消耗的详细报表呢?办法总比问题多,有需求就有解决方案。EC Bigdata team针对这个问题实现了一个 Redis 内存数据可视化分析平台 RCT (Redis Computed Tomography)。
RCT可以非常方便的对 Reids 的内存进行分析,了解一个 Redis 实例里都有哪些 key,哪类 key 占用的空间是多少,最耗内存的 key 有哪些,占比如何,非常直观,除此之外,我们还可以针对Redis slowlog/clientlist进行分钟级别监控,直观监控集群效应状况。
市面上已经存在这么多开源的产品,我们为什么还要重新做一个呢?主要还是没有满足我们的需求,以上的都是redis rdb解析工具,最接近我们需求的就是雪球开源的rdr,但是也只限于离线分析,而我们节点众多,不可能一个一个去线上机器copy,或者开发copy工具,这样也会给相应机器带来网络热点(总有办法解决这个问题),带来很多繁重无意义的劳动,么不是专门的运维工程师,还有更多的开发任务等着我们去做。
我们想要一个每天都会给我们产生报表,自动推送到我们的邮箱,或者在网页上就能看到最近redis内存的变化,它不仅仅是一个工具,还是常态化运行的服务,基于此我们打造了属于最近的redis内存分析平台RCT。
使用 bgsave,获取 rdb 文件,解析后获取数据。
优点:机制成熟,可靠性好;文件相对小,传输、解析效率高;
缺点:bgsave 虽然会 fork 子进程,但还是有可能导致主进程卡住一段时间,对业务有产生影响的风险;
采用低峰期在从节点做 bgsave 获取 rdb 文件,相对安全可靠。拿到了 rdb 文件就相当于拿到了 Redis 实例的所有数据,接下来就是生成报表的过程了:
解析 rdb 文件,获取到 Key 和 Value 的内容;根据相对应的数据结构及内容,估算内存消耗等;统计并生成报表;逻辑很简单,所以设计思路很清晰。
为了使对线上机器不产生影响,我们选择是在slave节点进行rdb文件分析,该任务是分布式的。为了均衡对每个机器的影响,通过算法去保证slave分配算法均匀的落在不同的机器上。
1 | /** |
redis中支持多种内存分配算法,推荐Jemalloc,因此我们选择该算法来预估内存大小。因为这个算法比较复杂,我们参考雪球做法使用约定数组,根据不同数据大小分配不同内存空间,为了提高查找效率,这块采用了变种二分查找。
1 | public class Jemalloc { |
详见redis源码
1 | private static final long redisObject = (long)(8 + 8); |
RCT是一个一站式redis内存分析分析平台,分析任务是分布式的,需要将RCT-Analyze部署到rdb所在机器上,RCT-Dashboard部署在任何机器,只要能保持和RCT-Analyze通信即可。不同于以上列举的工具,我们最初定位RCT就是一个可以长期运行,尽可能每天分析redis中数据,为redis运维人员提供运维依据,便于做出更好的规范,高效的使用redis。
部署过程略,详见官方文档,推荐使用docker方式,这样也是我们目前采用的方式。
只有先创建了redis节点之后,才能进入到RCT工具导航页面。
RDB主页面参数与add页面参数基本相同,在此不再做赘述,唯一有区别的是:
Status:分析RDB文件的进度状态,分为成功,正在分析,失败三种状态,status为正在分析状态时,可通过点击后面的链接进入到实时分析页面,查看实时状态。
点击Analyze,则是对RDB信息进行手动分析,分析进行的状态可在status中查看,可以通过status后面的链接进入到实时查看rdb分析任务的进度状态
目前RCT支持dashboard/email两种方式,这里我仅展示dashboard.
https://github.com/xaecbd/RCT,欢迎使用,欢迎加入我们,帮我们提高RCT。如果你有问题,可以前往github新建issue。