Objective-C 初体验 -- 语法篇

	TDH_SOCKET	HandlerSocket	SQL
IO策略	Dynamic IOStrategy	Same-thread IOStrategy	one-thread-per-connection
优点	worker线程只处理与DB相关的逻辑最大化DB的操作吞吐量	上下文切换真心很少	资源分离不太会相互干扰
缺点	上下文切换一般,测试时最高在10w,但可以接受	IO逻辑对DB逻辑影响较大一旦io处理的慢了,会导致QPS下降很多(比如说较多的连接数并发请求导致io处理变慢也会是整体QPS下降)	线程资源浪费严重,太多的线程会导致高并发是上下文切换多,从而影响性能,测试时最高60w
读策略	无需SQL解析可在THD上cache open过的table(可配置关闭) 一次轮询只lock一次table 请求按table的hash值平均分配到可活动的线程上如果有table被过多访问,那么此table的请求可被分配到多个线程上在带io请求少时,可以用较少的线程work.来减少锁征用导致的上下文切换有一定量带io请求时,能调整worker线程数来充分利用io资源. 当带io请求巨多时,将区分带io的请求和不带io的请求.分别用两个线程池来执行,防止带io的请求堵住不带io的请求. 还可以设置流控带io的请求数来防止client的堵塞情况,能使DB继续输出较高的QPS 如果返回大批量数据可以以stream的方式返回,避免过多占用内存	无需SQL解析可在THD上cache open过的table(不可配置关闭) 一次轮询只lock一次table worker线程数固定,且无法做请求数的平衡,只能做连接数的平衡	可global的做table的cache 每次请求都lock一次table
优点	多种策略配合能一直输出较高的QPS	在全缓存的请求下,输出的QPS很高	由于是一个连接一个请求,不会出现由带io的请求堵塞不带io的请求的情况出现
缺点	流控会丢失一部分请求, 预测请求带不带io不是非常准确 (如果使用row cache就能较精确的预测了)	一旦有带io的请求出现,就很容易堵塞住不带io的请求出现,所以缓存命中率下降后QPS下降的非常厉害返回大批量数据会占用过多内存	有极限一般QPS最高输出到6-7w
写策略	一次轮询的请求一次commit 请求按table的hash值平均分配到写线程上,即同一个表肯定在一个写线程的被执行,不会有死锁的问题,也不会有同一条row的锁问题. 支持Batch方式的小事务,Batch内的请求保证同时成功,同时失败可以在Client端通过指定hash的方式,来控制请求被指定的线程执行,来避免一些锁或死锁	一次轮询的请求一次commit 可配置多个写线程,但是有一个user_lock保证只有一个写线程在工作,来防止死锁	一次请求一次commit
优点	同一个表必然在同一个线程上执行,所以行锁的征用被降到最低,加上group commit就能提供很搞的TPS 可以多个写线程并发写,不会有死锁问题支持batch小事务	Group commit可以减少fsync次数,提高写性能	支持大事务
缺点	写线程数有限,在有io堵塞请求下,性能会有下降	同一时刻只有一个写线程能被执行,很容易达到瓶颈,一旦有多表插入并发出现,很容易影响整体更新性能生成binlog没有执行时间(bug) 多表insert会有自增id获取失败的问题(bug)	性能受限于IOPS
可维护性	DDL操作不会被hang住(因为可以主动close 被cache的table) 支持KILL 命令直接终止正在执行的操作大部分参数都为在线可配置 status数据监控完善	DDL会被hang住,因为handlersocket只open table不管主动close table,只有在流量较小time out时才会close table	最高
易用性	client端不需要openIndex,直接请求即可(如: client.query().use("test").select("id", "a", "b", "c").from("t") .where().fields("a").in(["1", "1"], ["2"], ["1"]).get()) server端只需要一个port 就能做读写分离可支持一些MySQL的内置函数现在支持Update/Insert的时候可以插入now() 基于辅助索引的联合主键可以支持简单的order by 只能支持=的order by Java客户端支持JDBC	读写分离需要在server端配置两个port是实现 client请求前需要先openIndex	最高

TDH_Socket开源介绍

By 淘宝文通

发表于 2012-05-16

TDH_Socket开源啦

源码地址: https://github.com/alibaba/TDH_Socket

同时还开源了Java客户端: https://github.com/alibaba/tdhs-java-client

现在介绍一下TDH_Socket:

TDH_Socket是一个MySQL daemon plugin 类似于HandlerSocket(https://github.com/DeNADev/HandlerSocket-Plugin-for-MySQL)

现在TDH_Socket能接受客户端的TCP请求,并且直接通过MySQL的Handler层访问数据,绕开了SQL解析等一系列逻辑

TDH_Socket的Java客户端可以通过在客户端解析SQL的方式提供JDBC接口来提高易用性,并且也不会降低性能

TDH_Socket的一些特性和优点:

具有HandlerSocket的全部功能
连接复用,采用动态IO策略,只使用一个port进行通讯
进行DDL操作时不会hang住(可手动关闭被cache住的表)
支持流输出,对于大数量的返回,不会占用太多内存

易用

1.  不需要在一开始open&#95;table,会在具体执行时open&#95;table,被open的table还是会被当前线程cache住,下次请求不需要再次open

Java客户端支持JDBC,在客户端进行SQL解析

支持多线程的并发写操作
```
1.  默认情况下,对一个表的写操作都会在一个固定的线程被执行,从而避免可能的死锁
```
1. 也可以通过配置使一个表的写操作被多个线程并发执行,但是可能会导致死锁而进行回滚
2. 客户端可以将写请求发给指定的线程执行,可以在客户端那边在逻辑上保证不会死锁
读线程的动态调整
由于采用读写分开以及物理读和逻辑读的线程分开策略使在有大量物理读的时候也能提供比较高的性能
能对物理读进行流控