摘要: 一 前言 PolarDB是阿里巴巴自研的新一代云原生关系型数据库,在存储计算分离架构下,利用了软硬件结合的优势,为用户提供具备极致弹性、海量存储、高性能、低成本的数据库服务。X-Engine是阿里巴巴自研的新一代存储引擎,作为AliSQL的核心引擎之一已广泛用于阿里巴巴集团核心业务,包括交易历史库, 阅读全文
posted @ 2021-12-29 21:16 天士梦 阅读(938) 评论(0) 推荐(0) 编辑
摘要: 概述 MySQL经过多年的发展已然成为最流行的数据库,广泛用于互联网行业,并逐步向各个传统行业渗透。之所以流行,一方面是其优秀的高并发事务处理的能力,另一方面也得益于MySQL丰富的生态。MySQL在处理OLTP场景下的短查询效果很好,但对于复杂大查询则能力有限。最直接一点就是,对于一个SQL语句, 阅读全文
posted @ 2020-02-22 21:06 天士梦 阅读(6310) 评论(1) 推荐(5) 编辑
摘要: 概述&背景 MySQL一直被人诟病没有实现HashJoin,最新发布的8.0.18已经带上了这个功能,令人欣喜。有时候在想,MySQL为什么一直不支持HashJoin呢?我想可能是因为MySQL多用于简单的OLTP场景,并且在互联网应用居多,需求没那么紧急。另一方面可能是因为以前完全靠社区,这种演进 阅读全文
posted @ 2019-11-30 11:42 天士梦 阅读(6013) 评论(0) 推荐(3) 编辑
摘要: 背景 现在主流的数据库系统的故障恢复逻辑都是基于经典的ARIES协议,也就是基于undo日志+redo日志的来进行故障恢复。redo日志是物理日志,一般采用WAL(Write-Ahead-Logging)机制,所以也称redo日志为wal日志,redo日志记录了所有数据的变更,undo日志是逻辑日志 阅读全文
posted @ 2019-11-10 21:30 天士梦 阅读(2328) 评论(1) 推荐(0) 编辑
摘要: 概述 越来越多的企业选择上云,最基础的云服务就是IaaS(Infrastructure as a Service)服务,直观理解就是虚拟主机,用户不用再自建机房,自己购买服务器,而是直接向云厂商购买虚拟主机服务ECS(Elastic Compute Service),按时按量付费。对于数据库而言,将 阅读全文
posted @ 2019-08-18 08:58 天士梦 阅读(1904) 评论(0) 推荐(0) 编辑
摘要: 概述 NewSQL日渐火热,无论还是开源的TiDB,CockroachDB还是互联网大厂的Spanner,Oceanbase都号称NewSQL,也就是分布式数据库。NewSQL的典型特征就是,支持SQL,支持事务,高性能,低成本,高可靠,强一致,易扩展,运维友好等。从NewSQL的演进来看,所谓Ne 阅读全文
posted @ 2019-04-14 09:24 天士梦 阅读(1914) 评论(0) 推荐(1) 编辑
摘要: 概述 数据库相对于其它存储软件一个核心的特征是它支持事务,所谓事务的ACID就是原子性,一致性,隔离性和持久性。其中原子性,一致性,持久性更多是关注单个事务本身,比如,原子性要求事务中的操作要么都提交,要么都不提交;一致性要求事务的操作必须满足定义的约束,包括触发器,外键约束等;持久性则要求如果事务 阅读全文
posted @ 2019-03-31 19:58 天士梦 阅读(1427) 评论(0) 推荐(1) 编辑
摘要: 概述 在单机数据库领域,我们为每个事务都分配一个序列号,比如Oracle的SCN(SystemChangeNumber),MySQL的LSN(LogSequenceNumber),这个序列号可以是逻辑的,也可以是物理的。我们依赖这个序列号对系统中发生的事务进行排序,确保所有事务都有严格的先后关系。数 阅读全文
posted @ 2019-03-25 09:25 天士梦 阅读(2737) 评论(4) 推荐(1) 编辑
摘要: Amazon在SIGMOD 2017发表了论文《Amazon Aurora: DesignConsiderations for High Throughput Cloud-Native Relational Databases》,第一次公开介绍了Aurora的设计理念和内部实现,下文是我对论文的解读 阅读全文
posted @ 2017-09-05 09:22 天士梦 阅读(14351) 评论(0) 推荐(3) 编辑
摘要: RocksDB作为一个开源的存储引擎支持事务的ACID特性,而要支持ACID中的I(Isolation),并发控制这块是少不了的,本文主要讨论RocksDB的锁机制实现,细节会涉及到源码分析,希望通过本文读者可以深入了解RocksDB并发控制原理。文章主要从以下4方面展开,首先会介绍RocksDB锁 阅读全文
posted @ 2017-07-03 08:54 天士梦 阅读(6887) 评论(1) 推荐(0) 编辑
摘要: 最近一个日常实例在做DDL过程中,直接把数据库给干趴下了,问题还是比较严重的,于是赶紧排查问题,撸了下crash堆栈和alert日志,发现是在去除唯一约束的场景下,MyRocks存在一个严重的bug,于是紧急向官方提了一个bug。其实问题比较隐蔽,因为直接一条DDL语句,数据库是不会挂了,而是在特定 阅读全文
posted @ 2017-04-17 08:43 天士梦 阅读(2137) 评论(0) 推荐(2) 编辑
摘要: 概述 前几天排查了一个死锁问题,最开始百思不得其解,因为发生死锁的两个事务是单语句事务,语句类型相同(where属性列相同,仅值不同),而且语句都走了相同的索引,但最终确实发生了死锁。通过定位排查发现,问题的源头就是index_merge,死锁的原因也很普通,两个事务加锁顺序不同,并存在相互等待的情 阅读全文
posted @ 2017-02-27 09:19 天士梦 阅读(3130) 评论(1) 推荐(4) 编辑
摘要: 背景 mysql可以支持多种不同的存储引擎,innodb由于其高效的读写性能,并且支持事务特性,使得它成为mysql存储引擎的代名词,使用非常广泛。随着SSD逐渐普及,硬件存储成本越来越高,面向写优化的rocksdb引擎逐渐流行起来,我们也是看中了rocksdb引擎在写放大和空间放大的优势,将其引入 阅读全文
posted @ 2016-12-29 08:38 天士梦 阅读(1047) 评论(0) 推荐(0) 编辑
摘要: 概述 compaction主要包括两类:将内存中imutable 转储到磁盘上sst的过程称之为flush或者minor compaction;磁盘上的sst文件从低层向高层转储的过程称之为compaction或者是major compaction。对于myrocks来说,compaction过程都 阅读全文
posted @ 2016-10-28 13:28 天士梦 阅读(12338) 评论(1) 推荐(0) 编辑
摘要: Rocksdb是一个kv引擎,由facebook团队基于levelDB改进而来,Rocksdb采用LSM-tree存储数据,良好的读写特性以及压缩特性使得其非常受欢迎。此外,Rocksdb引擎作为插件已经集成在facebook维护的MySQL分支,用户可以通过SQL来访问rocksDB。本文主要通过 阅读全文
posted @ 2016-10-17 08:08 天士梦 阅读(5133) 评论(1) 推荐(0) 编辑
摘要: 1.启动调试 前置条件:编译生成执行码时带上 -g,如果使用Makefile,通过给CFLAGS指定-g选项,否则调试时没有符号信息。gdb program //最常用的用gdb启动程序,开始调试的方式gdb program core //用gdb查看core dump文件,跟踪程序core的原因g 阅读全文
posted @ 2016-08-06 16:02 天士梦 阅读(7499) 评论(1) 推荐(0) 编辑
摘要: 前面一篇文章讲了Paxos协议,这篇文章讲它的姊妹篇Raft协议,相对于Paxos协议,Raft协议更为简单,也更容易工程实现。有关Raft协议和工程实现可以参考这个链接https://raft.github.io/,里面包含了大量的论文,视屏已经动画演示,非常有助于理解协议。概念与术语leader 阅读全文
posted @ 2016-07-04 08:00 天士梦 阅读(6259) 评论(1) 推荐(3) 编辑
摘要: Paxos算法是莱斯利·兰伯特(Leslie Lamport)1990年提出的一种基于消息传递的一致性算法。Paxos算法解决的问题是一个分布式系统如何就某个值(决议)达成一致。在工程实践意义上来说,就是可以通过Paxos实现多副本一致性,分布式锁,名字管理,序列号分配等。比如,在一个分布式数据库系 阅读全文
posted @ 2016-06-27 09:04 天士梦 阅读(30488) 评论(1) 推荐(6) 编辑
摘要: 无论逻辑备份还是物理备份,为了获取一致性位点,都强依赖于FTWRL(Flush Table With Read Lock)。这个锁杀伤力非常大,因为持有锁的这段时间,整个数据库实质上不能对外提供写服务的。此外,由于FTWRL需要关闭表,如有大查询,会导致FTWRL等待,进而导致DML堵塞的时间变长。 阅读全文
posted @ 2016-06-05 08:53 天士梦 阅读(6479) 评论(5) 推荐(0) 编辑
摘要: 上周去参加了2016 DTCC(数据库技术大会),会议总共持续3天,议题非常多,我这里搜集了最新的公开的PPT内容,有兴趣的同学可以下载看看,PPT合集下载链接为:http://pan.baidu.com/s/1i4XDESX。以下内容是我对听的几个议题的一点总结,并欢迎讨论。 《时间序列存储引擎》 阅读全文
posted @ 2016-05-19 11:31 天士梦 阅读(3339) 评论(4) 推荐(6) 编辑

概述

      在开发过程中,我们经常会遇到并发问题,解决并发问题通常的方法是加锁保护,比如常用的spinlock,mutex或者rwlock,当然也可以采用无锁编程,对实现要求就比较高了。对于任何一个共享变量,只要有读写并发,就需要加锁保护,而读写并发通常就会面临一个基本问题,写阻塞读,或则写优先级比较低,就会出现写饿死的现象。这些加锁的方法可以归类为悲观锁方法,今天介绍一种乐观锁机制来控制并发,每个线程通过线程局部变量缓存共享变量的副本,读不加锁,读的时候如果感知到共享变量发生变化,再利用共享变量的最新值填充本地缓存;对于写操作,则需要加锁,通知所有线程局部变量发生变化。所以,简单来说,就是读不加锁,读写不冲突,只有写写冲突。这个实现逻辑来源于Rocksdb的线程局部缓存实现,下面详细介绍Rocksdb的线程局部缓存ThreadLocalPtr的原理。

线程局部存储(TLS)

简单介绍下线程局部变量,线程局部变量就是每个线程有自己独立的副本,各个线程对其修改相互不影响,虽然变量名相同,但存储空间并没有关系。一般在linux 下,我们可以通过以下三个函数来实现线程局部存储创建,存取功能。

int pthread_key_create(pthread_key_t *key, void (*destr_function) (void*)), 
int pthread_setspecific(pthread_key_t key, const void *pointer) ,
void * pthread_getspecific(pthread_key_t key)

ThreadLocalPtr类

     有时候,我们并不想要各个线程独立的变量,我们仍然需要一个全局变量,线程局部变量只是作为全局变量的缓存,用以缓解并发。在RocksDB中ThreadLocalPtr这个类就是来干这个事情的。ThreadLocalPtr类包含三个内部类,ThreadLocalPtr::StaticMeta,ThreadLocalPtr::ThreadData和ThreadLocalPtr::Entry。其中StaticMeta是一个单例,管理所有的ThreadLocalPtr对象,我们可以简单认为一个ThreadLocalPtr对象,就是一个线程局部存储(ThreadLocalStorage)。但实际上,全局我们只定义了一个线程局部变量,从StaticMeta构造函数可见一斑。那么全局需要多个线程局部缓存怎么办,实际上是在局部存储空间做文章,线程局部变量实际存储的是ThreadData对象的指针,而ThreadData里面包含一个数组,每个ThreadLocalPtr对象有一个独立的id,在其中占有一个独立空间。获取某个变量局部缓存时,传入分配的id即可,每个Entry中ptr指针就是对应变量的指针。

ThreadLocalPtr::StaticMeta::StaticMeta() : next_instance_id_(0), head_(this) {
  if (pthread_key_create(&pthread_key_, &OnThreadExit) != 0) {
    abort();
  }
  ......
}

void* ThreadLocalPtr::StaticMeta::Get(uint32_t id) const {
   auto* tls = GetThreadLocal();
   return tls->entries[id].ptr.load(std::memory_order_acquire);
}

struct Entry {
  Entry() : ptr(nullptr) {}
  Entry(const Entry& e) : ptr(e.ptr.load(std::memory_order_relaxed)) {}
  std::atomic<void*> ptr;
};

整体结构如下:每个线程有一个线程局部变量ThreadData,里面包含了一组ThreadLocalPtr的指针,对应的是多个变量,同时ThreadData之间相互通过指针串联起来,这个非常重要,因为执行写操作时,写线程需要修改所有thread的局部缓存值来通知共享变量发生变化了。

 ---------------------------------------------------
 |          | instance 1 | instance 2 | instnace 3 |
 ---------------------------------------------------
 | thread 1 |    void*   |    void*   |    void*   | <- ThreadData
 ---------------------------------------------------
 | thread 2 |    void*   |    void*   |    void*   | <- ThreadData
 ---------------------------------------------------
 | thread 3 |    void*   |    void*   |    void*   | <- ThreadData

struct ThreadData {
  explicit ThreadData(ThreadLocalPtr::StaticMeta* _inst)
      : entries(), inst(_inst) {}
  std::vector<Entry> entries;
  ThreadData* next;
  ThreadData* prev;
  ThreadLocalPtr::StaticMeta* inst;
};

读写无并发冲突

     现在说到最核心的问题,我们如何实现利用TLS来实现本地局部缓存,做到读不上锁,读写无并发冲突。读、写逻辑和并发控制主要通过ThreadLocalPtr中通过3个关键接口Swap,CompareAndSwap和Scrape实现。对于ThreadLocalPtr< Type* > 变量来说,在具体的线程局部存储中,会保存3中不同类型的值:

  1). 正常的Type* 类型指针;

  2). 一个Type*类型的Dummy变量,记为InUse;

  3). nullptr值,记为obsolote;

读线程通过Swap接口来获取变量内容,写线程则通过Scrape接口,遍历并重置所有ThreadData为(obsolote)nullptr,达到通知其他线程局部缓存失效的目的。下次读线程再读取时,发现获取的指针为nullptr,就需要重新构造局部缓存。

//获取某个id对应的局部缓存内容,每个ThreadLocalPtr对象有单独一个id,通过单例StaticMeta对象管理。
void* ThreadLocalPtr::StaticMeta::Swap(uint32_t id, void* ptr) {
//获取本地局部缓存
auto* tls = GetThreadLocal();                                        

  return tls->entries[id].ptr.exchange(ptr, std::memory_order_acquire);
}

bool ThreadLocalPtr::StaticMeta::CompareAndSwap(uint32_t id, void* ptr,
                                                void*& expected) {
  //获取本地局部缓存
  auto* tls = GetThreadLocal();
  return tls->entries[id].ptr.compare_exchange_strong(
      expected, ptr, std::memory_order_release, std::memory_order_relaxed);
}

//将所有管理的对象指针设置为nullptr,将过期的指针返回,供上层释放,
//下次进行从局部线程栈获取时,发现内容为nullptr,则重新申请对象。
void ThreadLocalPtr::StaticMeta::Scrape(uint32_t id, std::vector<void*>* ptrs, void* const replacement) {                           
  MutexLock l(Mutex());
  for (ThreadData* t = head_.next; t != &head_; t = t->next) {                               
    if (id < t->entries.size()) {                                                            
      void* ptr =
          t->entries[id].ptr.exchange(replacement, std::memory_order_acquire);               
      if (ptr != nullptr) {
  //搜集各个线程缓存,进行解引用,必要时释放内存
  ptrs->push_back(ptr);
      }                                                                            
    }
  } 
}

//初始化,或者被替换为nullptr后,说明缓存对象已经过期,需要重新申请。
ThreadData* ThreadLocalPtr::StaticMeta::GetThreadLocal() {
   申请线程局部的ThreadData对象,通过StaticMeta对象管理成一个双向链表,每个instance对象管理一组线程局部对象。
   if (UNLIKELY(tls_ == nullptr)) {
     auto* inst = Instance();
     tls_ = new ThreadData(inst);
     {                                                                        
      // Register it in the global chain, needs to be done before thread exit
      // handler registration                                                
      MutexLock l(Mutex());                                                  
      inst->AddThreadData(tls_);
     }
    return tls_;                                             
  }
}

读操作包括两部分,Get和Release,这里面除了从TLS中获取缓存,还涉及到一个释放旧对象内存的问题。Get时,利用InUse对象替换TLS对象,Release时再将TLS对象替换回去,读写没有并发的场景比较简单,如下图,其中TLS Object代表本地线程局部缓存,GlobalObject是全局共享变量,对所有线程可见。

下面我们再看看读写有并发的场景,读线程读到TLS object后,写线程修改了全局对象,并且遍历对所有的TLS object进行修改,设置nullptr。在此之后,读线程进行Release时,compareAndSwap失败,感知到使用的object已经过期,执行解引用,必要时释放内存。当下次再次Get object时,发现TLS object为nullptr,就会使用当前最新的object,并在使用完成后,Release阶段将object填回到TLS。

应用场景

      从前面的分析来看,TLS作为cache,仍然需要一个全局变量,全局变量保持最新值,而TLS则可能存在滞后,这就要求我们的使用场景不要求读写要实时严格一致,或者能容忍多版本。全局变量和局部缓存有交互,交互逻辑是,全局变量变化后,局部线程要能及时感知到,但不需要实时。允许读写并发,即允许读的时候,使用旧值读,待下次读的时候,再获取到新值。Rocksdb中的superversion管理则符合这种使用场景,swich/flush/compaction会产生新的superversion,读写数据时,则需要读supversion。往往读写等前台操作相对于switch/flush/compaction更频繁,所以读superversion比写superversion比例更高,而且允许系统中同时存留多个superversion。

每个线程可以拿superversion进行读写,若此时并发有flush/compaction产生,会导致superversion发生变化,只要后续再次读取superversion时,能获取到最新即可。细节上来说,扩展到应用场景,一般在读场景下,我们需要获取snapshot,并借助superversion信息来确认这次读取要读哪些物理介质(mem,imm,L0,L1...LN)。

1).获取snapshot后,拿superversion之前,其它线程做了flush/compaction导致superversion变化

这种情况下,可以拿到最新的superversion。

2).获取snapshot后,拿superversion之后,其它线程做了flush/compaction导致superversion变化

这种情况下,虽然superversion比较旧,但是依然包含了所有snapshot需要的数据。那么为什么需要及时获取最新的superversion,这里主要是为了回收废弃的sst文件和memtable,提高内存和存储空间利用率。

总结

     RocksDB的线程局部缓存是一个很不错的实现,用户使用局部缓存可以大大降低读写并发冲突,尤其在读远大于写的场景下,整个缓存维护代价也比较低,只有写操作时才需要锁保护。只要系统中允许共享变量的多版本存在,并且不要求实时保证一致,那么线程局部缓存是提升并发性能的一个不错的选择。

posted @ 2019-09-22 14:00 天士梦 阅读(2152) 评论(0) 推荐(0) 编辑
摘要: 并发模型 常见的并发模型一般包括3类,基于线程与锁的内存共享模型,actor模型和CSP模型,其中尤以线程与锁的共享内存模型最为常见。由于go语言的兴起,CSP模型也越来越受关注。基于锁的共享内存模型与后两者的主要区别在于,到底是通过共享内存来通信,还是通过通信来实现访问共享内存。由于actor模型 阅读全文
posted @ 2019-08-18 18:45 天士梦 阅读(1731) 评论(0) 推荐(1) 编辑
摘要: 1. DDL原子性概述 8.0之前并没有统一的数据字典dd,server层和引擎层各有一套元数据,sever层的元数据包括(.frm,.opt,.par,.trg等),用于存储表定义,分区表定义,触发器定义等信息;innodb层也有自己一套元数据,包括表信息,索引信息等,这两套元数据并没有机制保证一 阅读全文
posted @ 2019-07-01 09:34 天士梦 阅读(1707) 评论(0) 推荐(0) 编辑
摘要: 概述 MySQL中临时表主要有两类,包括外部临时表和内部临时表。外部临时表是通过语句create temporary table...创建的临时表,临时表只在本会话有效,会话断开后,临时表数据会自动清理。内部临时表主要有两类,一类是information_schema中临时表,另一类是会话执行查询时 阅读全文
posted @ 2019-05-20 07:57 天士梦 阅读(29276) 评论(0) 推荐(6) 编辑
点击右上角即可分享
微信分享提示