DBProxy

我们一直在追求架构的艺术！！ 问题分析 经过几分钟的排查，数据库情况如下： 数据库采用Sqlserver 2008 R2，单表数据量21亿。 无水平或者垂直切分，但是采用了分区表。分区表策略是按时间降序分的区，将近30个分区。正因为分区表的原因，系统才保证了在性能不是太差的情况下坚持至今。 此表除聚集索引之外，无其他索引，无主键（主键其实是利用索引来快速查重的）。所以在频繁插入新数据的情况下，索引调整所耗费的性能比较低。 至于聚集索引和非聚集索引等知识，请各位移步google或者百度。 至于业务，不是太复杂。经过相关人员咨询，大约40%的请求为单条Insert，大约60%的请求为按class_id 和in_time（倒序）分页获取数据。Select请求全部命中聚集索引，所以性能非常高。这也是聚集索引之所以这样设计的目的。 解决问题 由于单表数据量已经超过21亿，并且2017年以前的数据几乎不影响业务，所以决定把2017年以前（不包括2017年）的数据迁移到新表，仅供以后特殊业务查询使用。经过查询大约有9亿数据量。 数据迁移工作包括三个个步骤： 从源数据表查询出要迁移的数据 把数据插入新表 把旧表的数据删除 传统做法 这里申明一点，就算是传统的做法也需要分页获取源数据，因为你的内存一次性装载不下9亿条数据。 从源数据表分页获取数据，具体分页条数，太少则查询原表太频繁，太多则查询太慢。

1. 引言 分布式事务主要应用领域主要体现在 数据库领域、微服务应用领域。微服务应用领域一般是柔性事务，不完全满足 ACID 特性，特别是 I 隔离性，比如说 saga 不满足隔离性，主要是通过根据分支事务执行成功或失败，执行相应的前滚的重试或者后滚的补偿操作来达成全局事务的最终一致性，但是全局事务与全局事务之间没有隔离性。 笔者了解到的分布式事务方案有 2PC 的 XA 规范，以及 Google 的 percolator 方案（ TiDB 就采用这个实现，本质上是基于全局时间戳的乐观锁版本校验）。 mysql 的 XA 应用场景分为外部 XA 与内部 XA ，内部 XA 用于 binlog 与 stroage engine 之间，协调 binlog 与 redo 事务写入的原子性。外部 XA 用于 mysql 节点与 mysql 节点之间，协调跨物理库之间的原子性。本文主要介绍外部 XA 。 基于 mysql 的 XA 两阶段事务提交(2PC) 分布式事务，需要一个事务协调器（ TransactionManager ）来接受应用提交的全局事务 (Global Transaction) ，全局事务经过 TM 的分解后，分解成多个分支事务 (Branch Transaction) ，每个分支事务在具体的某个 mysql 实例上运行，其中 mysql 作为资源管理器（ Resource

mars/火星实时物联数据库 High performance realtime database.Our goal is to store the second level data of 3-10 million sensors on a single server. 以记录物联网时代各种传感器数据为目的的，高性能实时传感器数据库。相较于传统工业系统中的实时库，该库提供了基于互联网的各种特性，相较于时序库该库提供了以单个传感器数据（变量）为记录单位的记录和管理数据的方式较时序库仍然以表为记录单位方式的不同。该项目的目标：在单台服务器上达到 300~1000万 个传感器数据按照秒级变化的数据的历史存储，分布式版本可以达到 上亿以及十亿级别 。 目前测试的结果是，在如下配置的商务台式电脑上可以达到 100 万个传感器数据按照秒级变化的历史存储。 CPU： I7 4790,主频：3.6 内存：8G 磁盘: 机械磁盘 512G,7200转 功能 实时数据服务。提供数据的实时值的查询、修改服务。 历史数据存储。提供对实时数据按照秒级进行存储，存储类型包括定时、值变化存储2种模式。历史数据的压缩提供了： 无压缩 、 无损压缩 、 死区压缩 、 斜率死区压缩（旋转门算法） 4种压缩方式。 外部访问接口。基于 Web API 、 Grpc 、 OPC-UA 等各种上、下访问接口。 数据类型

一、如何实现MySQL主从读写分离 　　　　1、通过程序实现读写分离（性能，效率最佳，推荐） 　　　　php和java程序都可以通过设置多个连接文件轻松的实现对数据库的读写分离，即当select时，就去连接读库的连接文件，当updata，insert，delete时就连接写库的连接文件。 　　　　2、通过软件实现读写分离 　　　　MySQL-proxy，Amoeba等代理软件也可以实现读写分离功能， 但最常用好用的还是程序实现读写分离。 　　　　3、开发dbproxy 二、主从复制原理图： 三、MySQL主从复制原理过程 　　　　1、同步的时候，从库有俩个线程完成IO、SQL线程，主从有一个线程完成IO线程。 　　　　2、要在从库上面配置连接主库的IP、用户名、账号、密码、文件的位置、以及pos点等。 　　　　3、开启开关之前，要确保主从库是一致的。 　　　　4、要在主库上建立专门用于从库同步的账号。 　　　　5、主库要打开binlog开关，否则无法实现同步。 　　　　6、从库打开开关的过程，其实就是让IO，SQL线程工作的过程 来源： oschina 链接： https://my.oschina.net/u/4294821/blog/4114896

前言 大家可以从任何一个gii生成model类开始代码上溯，会发现：yii2的model层基于ActiveRecord实现DAO访问数据库的能力。 而ActiveRecord的继承链可以继续上溯，最终会发现model其实是一个component，而component是yii2做IOC的重要组成部分，提供了behaviors，event的能力供继承者扩展。 （IOC，component，behaviors，event等概念可以参考http://www.digpage.com/学习） 先不考虑上面的一堆概念，一个站点发展历程一般是1个库1个表，1个库N个表，M个库N个表这样走过来的，下面拿订单表为例，分别说说。 1）1库1表：yii2默认采用PDO连接mysql，框架默认会配置一个叫做db的component作为唯一的mysql连接对象，其中dsn分配了数据库地址，数据库名称，配置如下： ? 1 2 3 4 5 6 7 8 'components' => [ 'db' => [ 'class' => 'yii\db\Connection' , 'dsn' => 'mysql:host=10.10.10.10;port=4005;dbname=wordpress' , 'username' => 'wp' , 'password' => '123' , 'charset' =>