OceanBase使用libeasy原理源码分析:客户端

本文深入探讨 OceanBase 0.4 版本中 libeasy 客户端如何利用异步与同步请求机制,通过分析 easy_session_t 等关键数据结构,解释了请求分发、数据包发送与接收的流程,揭示了 libeasy 如何在客户端实现高效的数据传输。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

这篇主要写libeasy作为客户端的情形。结合OceanBase 0.4的mergeserver使用libeasy的情况进行分析,mergeserver请求chunkserver是异步请求,chunkserver使用update是同步请求,在libeasy中,同步请求是通过异步请求来实现。使用libeasy作为服务器端的情况见

作为客户端使用时,会涉及到一些数据结构,easy_session_t, easy_client_t, easy_hash_t, easy_hash_list_t等。

easy_session_t用来封装一个要发出去的请求,easy_client_t用来封装一个TCP连接的发起端,easy_hash_t是一个哈希表,easy_hash_list_t是采用开放寻址解决hash冲突的链表节点

一、 异步请求

二、同步请求

 

一、异步请求

在OceanBase 0.4 中,mergeserver请求chunkserver是异步的方式。实际使用了libeasy的如下两个上层接口:

easy_session_t *easy_session_create(int64_t asize)

int easy_client_dispatch(easy_io_t *eio, easy_addr_t addr, easy_session_t *s)

首先看看session这个关键的数据结构:

 

#define EASY_MESSAGE_SESSION_HEADER \
      easy_connection_t *c; \
      easy_pool_t *pool; \
      int8_t type; \
      int8_t async; \ //1 代表这是个异步session
      int8_t status; \
      int8_t error;
struct easy_session_t {
      EASY_MESSAGE_SESSION_HEADER;
      ev_tstamp               timeout, now;
      ev_timer                timeout_watcher;
      // 用于串入session list的链表节点
      easy_list_t             session_list_node;
      //为了快速根据packet id定位到发送队列中的session,将session加入到发送队列中时,同时,将其加入到一个hash表中,hash表采用链表的方式将同一个bucket的元素连接起来,
      //链表元素就是easy_hash_list_t类型
      easy_hash_list_t        send_queue_hash;
      // 用于串入发送队列链表的节点
      easy_list_t             send_queue_list;
      // 当session的包返回时处理响应的回调函数,对于OceanBase 0.4的mergeserver来说,实际上是int ObMergeCallback::sql_process(easy_request_t* r)
      // 将响应事件进mergeserver的finish queue队列
      easy_io_process_pt     *process;
      easy_io_cleanup_pt     *cleanup;
      easy_addr_t             addr;
      easy_list_t            *nextb;
// 用于作为session的hash key,用于收到session响应时快速的从发送队列中删除相应的session uint64_t packet_id; // 各种回调函数的集合 void *thread_ptr; //该session封装的请求,一个session只封装一个请求 easy_request_t r; char data[0]; };

libeasy作为客户端时,将每个发往libeasy服务器端的请求包封装成一个session(easy_session_t),客户端将这个session放入连接的队列中然后返回,随后收到包后,将相应的session从连接的发送队列中删除,使用了hash加快查找,以packet id为hash key。在超时处理上,tbnet的包超时是基于连接的,即在一个连接上的所有的包的超时时间是一样的。libeasy的超时粒度基于包,得益于底层libev实现的watcher机制。

发包:

mergeserver给chunkserver发异步请求时,会首先分配一块内存,用来容纳easy_session_t和请求包,通过easy_session_t *easy_session_create(int64_t asize)函数来实现,这个函数主要就做了一件事:分配一个内存池easy_pool_t,在内存池头部放置一个easy_session_t,剩下部分存放实际的数据包ObPacket,然后将session的type设置为EASY_TYPE_SESSION。

随后,将实际包挂在这个session包装的request的opacket上,设置session的目标server地址,最后通过easy_session_set_timeout设置这个session的超时时间timeout,这也就是这个请求的超时时间。

然后调用int easy_client_dispatch(easy_io_t *eio, easy_addr_t addr, easy_session_t *s)将这个session分发到具体TCP连接:

1. 调用easy_thread_pool_hash 从IO线程池中选一个IO线程来执行这次session的发送

2. 将这个session加入到这个IO线程的session list中

3. 唤醒这个IO线程开始干活

如上一篇中介绍,IO线程被唤醒的回调函数easy_connection_on_wakeup,继而调用easy_connection_send_session_list函数,这个函数主要做几件事

1. 对于每个session,调用easy_connection_do_client,找到一条connection用于发送这个session

         1.1 从IO线程的client_list(easy_hash_t)这个hash table中找出一个easy_client_t(封装一个connection的发起端),对端地址是session->addr

         1.2 如果要发送的session是一个正常的session,则设置其回调函数process后,返回这个client封装的connection,如果是一个连接的session,并且没有现成的到对端的connection,则从IO线程的client_array(easy_array_t)中拿一个空闲的easy_client_t槽位,然后初始化它,并将其加入到IO线程的client_list中,再调用easy_connection_do_connect建立到对端的连接,最后返回该连接。如果是一个断开的session,则将这个client从client_list删除,并且将client占的槽位还给client_array。

2. 调用easy_connection_session_build:

          2.1. 设置session的cleanup函数

          2.2 调用easy_connection_get_packet_id(回调应用层定义的get_packet_id函数,对于OceanBase 0.4来说,对于packet的channel以一递增),为session封装的请求产生packet id,主要用于接收到session的响应时用于快速定位到发送队列将session删除。

          2.3 回调应用层定义的encode函数,在这里,是int ObTbnetCallback::encode(easy_request_t *r, void *data)函数,在请求所在message的pool分配一个easy_buf_t,并且将包拷进去,然后调用easy_request_addbuf将这个新的buf挂在连接的output输出缓冲区链表中。

          2.4 调用easy_hash_dlist_add(c->send_queue, s->packet_id, &s->send_queue_hash, &s->send_queue_list)将这个session添加到连接的发送队列中。这个函数将session添加到发送队列的同时,同时将相应的项添加到hash表的相应的bucket的链表头(easy_hash_t和easy_hash_list_t实现)

          2.5 将session串入到连接的session list中。并且启动timeout watcher,事件为之前为session设置的timeout时间

3. 调用easy_connection_write_socket将所有这些session被分发到的connection的output输出缓冲区链表的数据写出。

 收包:

如前所述,当fd可读时,会回调easy_connection_on_readable

从内核缓冲区读入数据到应用层输入缓冲区中读入数据,一样,会初始化一个easy_message_t m存放请求,m的初始引用计数为1然后调用easy_connection_do_response进行处理,libeasy作为服务器端时,调用的是easy_connection_do_request

easy_connection_do_response做几件事:

1. 回调应用层定义的decode的,从message的inputbuffer中解析出一个个的packet,将packet挂在session封装的请求r的ipacket上,并且将整个message挂在session封装的请求r的后面,相当于将请求和响应关联起来(s->r.request_list_node.next = (easy_list_t *) m)。对于OceanBase来说,是ObPacket, 由于是异步请求(s->async==1),将m的引用计数加1,并且同样,调用easy_connection_get_packet_id方法得到这个packet的packetid,然后调用s = (easy_session_t *) easy_hash_dlist_del(c->send_queue, packet_id)将这个packet所属的session从发送队列中摘下来

2. 由于这个session的响应收到了,将其timeout watcher停掉

3. 将这个session从连接的session list中删除

4. 调用easy_session_process

    4.1 回调应用层的process方法,在这里,是int ObMergeCallback::sql_process(easy_request_t* r),将包放入mergeserver的finish queue中。然后调用

easy_session_destroy(r->ms),该函数会调用easy_message_destroy(m, 0)将与这个session相关的响应message的引用计数减1,最后session使用的pool销毁。

5. 最后看是否message上是否还有request没处理完成,没有request要处理了,则调用easy_message_destroy(m, 1)将message的引用计数减1,将message从连接的message list删除,此时message引用计数为0,销毁message使用的pool。

二、同步请求

首先,同异步请求类似,也是先创建一个session,将数据包拷进去,不同的是,同步请求调用的是void *easy_client_send(easy_io_t *eio, easy_addr_t addr, easy_session_t *s)方法而不是int easy_client_dispatch(easy_io_t *eio, easy_addr_t addr, easy_session_t *s)

其实,同步是异步的一种特殊的情况,同步请求也是通过异步请求实现的。

 void *easy_client_send(easy_io_t *eio, easy_addr_t addr, easy_session_t *s)方法封装了异步请求用到的easy_client_dispatch,easy_client_send将session

的process置为easy_client_wait_process方法,然后初始化一个easy_client_wait_t wobj,随后调用easy_client_dispatch方法走异步请求那一套,接着让自己wait在

wobj包装的一个信号量上,当这个请求收到包的时候回调easy_client_wait_process方法,signal这个信号量,然后返回session封装的请求的ipacket

 

 

转载于:https://www.cnblogs.com/foxmailed/archive/2013/02/17/2910041.html

//供学习用,禁止用于商业用途。 2012.04.20   OceanBase解决什么问题   许多公司的核心资产是各种各样的商业数据,例如淘宝的商品、交易、订单、购物爱好等等,这些数据通常是结构化的,并且数据之间存在各种各样的关联,传统的关系数据库曾经是这些数据的最佳载体。然而,随着业务的快速发展,这些数据急剧膨胀,记录数从几千万条增加到数十亿条,数据量从百GB增加到数TB,未来还可能增加到数千亿条和数百TB,传统的关系型数据库已经无法承担如此海量的数据。OceanBase解决不断增加的结构化数据存储查询的问题。   从Eric Brewer教授的CAP(一致性C: Consistency, 可用性A: Availability,分区容错性P: Tolerance of network Partition)理论角度分析,作为电子商务企业,淘宝和其他公司的业务对一致性和可用性的要求高于分区容错性,数据特征是数据总量庞大且逐步增加,单位时间内的数据更新量并不大,但实时性要求很高。这就要求我们提供一套更加偏重于支持CA特性的系统,同时兼顾可分区性,并且在实时性、成本、性能等方面表现良好。   OceanBase的架构   OceanBase的逻辑架构简图    ▲   OceanBase架构的一些基本概念   主键   row key,也称为primary key,类似于DBMS的主键,DBMS不同的是,OceanBase的主键总是二进制字符串(binary string),但可以有某种结构。OceanBase以主键为顺序存放表格数据   sstable   一种数据存储格式,OceanBase用来存储一个或几个表的一段按主键连续的数据   tablet   一个表按主键划分的一个(前开后闭的)范围,通常包含一个或几个sstable,一个tablet的数据量通常在256MB左右   基准数据和动态数据   OceanBase以增量方式记录一段时间内的表格数据的增删改,从而保持着表格主体数据在一段时间内相对稳定,其中增删改的数据称为动态数据(通常在内存,也称为内存表),而一段时间内相对稳定的主体数据称为基准数据,基准数据和转储后(保存到SSD固态盘或磁盘)的动态数据以sstable格式存储   ChunkServer   保存基准数据的服务器,通常是多台,为了避免软件硬件故障导致的服务中断,同一份基准数据通常保存了3份并存储在不同ChunkServer上   UpdateServer   保存动态数据的服务器,一般是单台服务器。为了避免软件硬件故障导致的服务中断,UpdateServer记录commit log并通常使用双机热备   MergeServer   进行静态动态数据合并的服务器,常常ChunkServer共用一台物理服务器。MergeServer使得用户能够访问到完整的最新的数据   RootServer   配置服务器,一般是单台服务器。为了避免软件硬件故障导致的服务中断,RootServer记录commit log并通常采用双机热备。由于RootServer负载一般都很轻,所以它常常UpdateServer共用物理机器   冻结   指动态数据(也称为内存表)的更新到一定时间或者数据量达到一定规模后,OceanBase停止该块动态数据的修改,后续的更新写入新的动态数据块(即新的内存表),旧的动态数据块不再修改,这个过程称为冻结   转储   出于节省内存或者持久化等原因将一个冻结的动态数据块(内存表)持久化(转化为sstable并保存到SSD固态盘或磁盘上)的过程   数据合并(merge)   查询时,查询项的基准数据其动态数据(即增删改操作)合并以得到该数据项的最新结果的过程。此外,把旧的基准数据冻结的动态数据进行合并生成新的基准数据的过程也称为数据合并   联表(join)   一张表另一张或几张表基于主键的左连接关系,类似于DBMS的自然连接   COW   Copy on Write的缩写,在OceanBase中特指BTree在更新时复制数据备份写入,避免系统锁的技术手段   OceanBase的特点   OceanBase功能   OceanBase设计和实现的时候暂时摒弃了不紧急的DBMS的功能,例如临时表,视图(view),研发团队把有限的资源集中到关键点上,当前OceanBase主要解决数据更新一致性、高性能的跨表读事务、范围查询、join、数据全量及增量dump、批量数据导入。   OceanBase数据访问特点   虽然数据总量比较大,但跟许多行业一样,淘宝业务一段时间(例如小时或天)内数据的增删改是有限的(通常一天不超过几千万次到几亿次),根据这个特点,OceanBase把一段时间内的增删改等修改操作以增量形式记录下来(称之为动态数据,通常保存在内存中),这样也使得了主体数据在一段时间内保持了相对稳定(称之为基准数据)。   由于动态数据相对较小,通常情况下,OceanBase把它保存在独立的服务器UpdateServer的内存中。以内存保存增删改记录极大地提高了系统写事务的性能。此外,假如每条修改平均消耗100 Bytes,那么10GB内存可以记录100M(即1亿)条修改,且扩充UpdateServer内存即增加了内存中容纳的修改量。不仅如此,由于冻结后的内存表不再修改,它也可以转换成sstable格式并保存到SSD固态盘或磁盘上。转储到SSD固态盘后所占内存即可释放,并仍然可以提供较高性能的读服务,这也缓解了极端情况下UpdateServer的内存需求。为了应对机器故障,动态数据服务器UpdateServer写commit log并采取双机(乃至多机)热备。由于UpdateServer的主备机是同步的,因此备机也可同时提供读服务。   因为基准数据相对稳定,OceanBase把它按照主键(primary key,也称为row key)分段(即tablet)后保存多个副本(一般是3个)到多台机器(ChunkServer)上,避免了单台机器故障导致的服务中断,多个副本也提升了系统服务能力。单个tablet的尺寸可以根据应用数据特点进行配置,相对配置过小的tablet会合并,过大的tablet则会分裂。   由于tablet按主键分块连续存放,因此OceanBase按主键的范围查询对应着连续的磁盘读,十分高效。   对于已经冻结/转储的动态数据,OceanBase的ChunkServer会在自己不是太繁忙的时候启动基准数据冻结/转储内存表的合并,并生成新的基准数据。这种合并过程其实是一种范围查询,是一串连续的磁盘读和连续的磁盘写,也是很高效的。   传统DBMS提供了强大的事务性、良好的一致性和很短的查询修改响应时间,但数据规模受到严重制约,缺乏扩展性;现代云计算提供了极大的数据规模、良好的扩展性,但缺乏跨行跨表事务、数据一致性也较弱、查询修改响应时间通常也较长,OceanBase的设计和实现融合了二者的优势:   --------------------------------------------------------------------------------   UpdateServer:类似于DBMS中的DB角色,提供跨行跨表事务和很短的查询修改的响应时间以及良好的一致性。   ChunkServer:类似于云计算中的工作机(如GFS的chunk server),具有数据多副本(通常是3)、中等规模数据粒度(tablet大小约256MB)、自动负载平衡、宕机恢复、机器plug and play等特点,系统容量及性能可随时扩展。   MergeServer:结合ChunkServer和UpdateServer,获得最新数据,实现数据一致性。   RootServer:类似于云计算中的主控机(如GFS master),进行机器故障检测、负载平衡计算、负载迁移调度等。   --------------------------------------------------------------------------------   上述的DBMS和云计算技术的优势互补使得OceanBase既具有传统DBMS的跨行跨表事务、数据的强一致性以及很短的查询修改响应时间,还有云计算的海量数据管理能力、自动故障恢复、自动负载平衡以及良好的扩展性。   OceanBase当前在淘宝的应用   OceanBase现在已经应用于淘宝收藏夹,用于存储淘宝用户收藏条目和具体的商品、店铺信息,每天支持4~5千万的更新操作。等待上线的应用还包括CTU、SNS等,每天更新超过20亿,更新数据量超过2.5TB,并会逐步在淘宝内部推广,也期待外部合作者。   主要的性能数据   测试软硬件环境   Red Hat Enterprise Linux Server release 5.4 (Tikanga)   gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)   Intel(R) Xeon(R) CPU E5520 @ 2.27GH   ChunkServer & MergeServer:Memory 16GB Disk 300GB SAS*10 NO Raid   UpdateServer & RootServer:Memory 48GB Disk 300GB SAS*6 Raid1   测试环境部署简图   ▲   测试数据规模   21亿条数据,基准数据3备份。   测试Schema   两张表,其中表1中有21列,表2中11列。   其中表1中的11列和表2中的11列存在join关系。   单条记录大小为500字节。   测试性能曲线图   Range数据查询   ▲   单条数据查询   ▲   当压力最大时,ChunkServer单台输出数据90MB/S,已经接近了千兆网卡的极限   更新数据   ▲
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值