- 博客(15)
- 收藏
- 关注
RSS订阅原创 前置通知、环绕通知和后置通知
在Java中，AOP（Aspect-Oriented Programming，面向切面编程）是一种编程范式，它允许开发者将横切关注点（如日志记录、事务管理、安全等）从业务逻辑代码中分离出来，从而提高代码的模块性和可重用性。在Spring框架中，AOP的实现主要通过代理模式来完成。Spring AOP提供了三种类型的通知（Advice）：前置通知（Before advice）、环绕通知（Around advice）和后置通知（After advice）。
2025-02-15 16:48:23
552
原创 TiDB Cloud 简介
TiDB Cloud 是一个功能齐全的数据库即服务或（DBaaS）管理员门户管理员门户是TiDB Cloud的业务管理平台调试门户调试门户是TiDB Cloud的运营诊断平台DataDogDataDog是一款提供监控服务的SaaS。用户可以在TiDB Cloud上为自己的数据系统配置增量数据同步 (MySQL 协议或Kafka协议)，相应数据系统的可靠性由用户保证。内部部署:手动下载TIDB组件手动安装TIDB组件手动管理TiDB组件和工具。
2024-11-25 23:46:56
751
原创 TiDB 6.0 新特性
在三个数据中心上，分别分布式地存储数据，BeiJing的用户要访问T2表和T3表，T2表的大部分的leader角色都在BeiJing的TiKV-1上，follower有的在BeiJIng有的在NewYork，当去写数据的时候，数据复制不仅要在BeiJIng那去复制，也还要复制到NewYork，我还要访问T3表，T3表的大部分节点都在NewYork的数据中心，业务吞吐量受影响。又续约了：TiKV会将刚修改好的数据，重新载入缓存（refresh），刷新之后，去读的用户依旧可以从内存中去读，写又被阻塞。
2024-11-25 23:30:59
1045
原创 TiFlash
product有索引，从大量数据中找少量数据，它适合TiKV，把product表的过滤放到TiKV中，sales表没有过滤条件，但select又要求某一列的值，适合于TiFlash，再将结果放到TiDB Server中，去做表连接。到T1时刻，客户端向TiFlash去请求key = 1，key = 999，TiKV中绿色的部分已经读到idx = 108，Region有新数据了，黄色的还没有，现在一个有，一个没有，当去读取的时候，去问一下写到哪儿了。2.关于 TiFlash 的使用，描述不正确的是？
2024-11-25 23:27:18
470
原创 TiDB数据库HTAP概述
TiDB Server作为协调者，把每一个TiFlash拥有的列存的Region进行交换，相关的表到一个TiFlash上，在TiFlash上做表连接，每个TiFlash（MPP worker）都会做过滤。正确答案： C. 支持在线业务高并发、D. 同时支持 OLTP 和 OLAP 业务、E. 能够读取到一致性的数据。正确答案： B. MPP 架构可以作用于 TiKV 和 TiFlash 上的数据。B. MPP 架构可以作用于 TiKV 和 TiFlash 上的数据。A. MPP 架构的中间结果都在内存中。
2024-11-25 23:24:39
823
原创 TiDB数据库SQL执行流程
sql语句先到Protocol Layer接收，再到PD节点获取TSO(sql语句读的开始时间），再到词法解析和语法解析为AST语法树，到Compile模块，会区分点查和非点査，到Execute执行器，从TiKV中读取信息，读取的信息再交由Execute返回给用户。DML 语句写流程概要。
2024-11-25 23:22:57
872
原创 Placement Driver
执行计划会传到Executor（执行器），将执行的请求发给TiKV Client，到PD上去找在哪一个TiKV上，PD返回信息告诉TiKV Client，然后TiKV Client发送请求到指定的TiKV，把数据读出来。（如果去访问的时候，leader已经变了 ，bade off），Region Cache信息过旧。正确答案： C. isolation-level 要和数据中心（DC）对应，这样可以获得最大的可用性。C. PD 会周期性地查询 TiKV 的状态，不需要 TiKV 上报，目的是为了高效。
2024-11-25 23:11:48
3346
原创 TiKV － 读写与Coprocessor
raftstore pool ：线程池，收到写请求，将写请求转化为raft 日志，持久化日志，将日志发送给其他日志所在节点，其他的raftstore pool负责接收，将日志持久化到rocksdb raft中，当副本大多数TiKV节点返回append成功了，就认为Raft 日志做的修改，它committed。第三步：replicate：将raft 日志复制到其他的节点，其他的节点接受后，将raft 日志写到rocksdb raft中，持久化后，返回一个写入成功消息，
2024-11-25 23:08:22
925
原创 TiKV－Raft
分布式强一致性：TiDB 写数据，只写leader，leader会将写入的指令变成日志的方式，向所有follower去复制，当集群中的大多数节点都收到日志，并且持久化之后，认为这个日志committed（存进去了），leader把写入 apply到rocksdb 中，变成KV数据。<1>propose:操作被leader收到了，leader准备同步,把写入请求，变成一条写入日志（Raft log），存到日志文件里，持久化到rocksdb raft中。Region：键值对的集合，按照key有序排列。
2024-11-25 23:04:13
934
原创 TiKV－分布式事务
prewrite：修改数据，TiKV节点会用三个列族来存，第一个对应的是修改的新数据，业务上的id再加上事务开始的时间戳，Default，第二个存储锁信息，在整个分布式事务的模型里面，只给事务的第一行加一把主锁，其他修改的行多依附于主锁，锁加到Lock列族中，W：写锁（主锁）+信息，第三个对应提交信息。原来版本（看Transaction 1），在修改的时候不修改当前的数据，新生成一个副本，有两个副本，一个副本是未提交的，把Jack可以随便改，我读的是原来的（未提交的）。给两个副本一个时间戳，就可以了。
2024-11-25 23:02:06
597
原创 TiKV - 持久化
TiDB Server作为sql层，对外暴露这个MySQL的协议，负责接收客户端的连接，执行sql的解析和优化，最终它会生成一个分布式的执行计划，TiDB Server本身是无状态。WAL：（红线）先将数据写到磁盘中的日志文件中，再把数据写到内存中，（数据还在内存中，没有落到磁盘上，突然宕机了，再起时，内存中的数据是完全没有了，但是WAL日志里，可以重读日志，把数据恢复出来：故障修复，sync_log = true 在写入的时候，直接会调用，直接将数据写到磁盘中，不会经过操作系统的缓存）
2024-11-25 22:59:45
542
原创 TiDB Server
原理：首先用户发出DDL语句，由start job接收，start job会把DDL当作一个job，放到TiKV的任务队列中（job queue），在同一时间只有一个TiDB Server ，它的角色叫owner，owner模块中的workers模块会从job队列，去取中的第一个job去执行，执行完的job放到history queue中，再拿下一个。在这个流程中，事务开始时，系统会记录一个开始时间（这个开始时间可以是事务创建时的系统时间戳，或者是从某个时间源获取的时间戳，具体取决于系统的设计和要求）。
2024-11-25 22:54:43
1040
原创 TiDB体系架构：
TiDB可以扩展，多个会话连到TiDB Server上，可以在集群中增加节点，分走一部分会话，分走并发压力存储能力不够了，加TiKV节点，数据库容量变大不需要太多存储，回收TiKV节点天然的讲Region生成副本，默认是3个存储集群。
2024-11-22 10:29:42
982
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人