wangtaotao
TA的个人档案
wangtaotao个人页面-阿里云开发者社区
文章
167
问答
0
个人介绍
专注于互联网系统设计
擅长的技术
- 高分内容
- 最新动态
- 文章
- 问答
-
发表了文章 2017-09-23
业务初期野蛮生长阶段,微服务化比较麻烦
谈谈后端业务系统的微服务化改造本文所提倡的微服务，是结合作者所在team自身业务特点来说的，适合自身的场景，是建立在团队人员素质到了，有成熟的基础设施和框架、中间件辅助，流程也规范，包括CI、敏捷等，团队都做好了准确去做这个转变，有足够的能力来实施，微服务化也就是水到渠成的事了。相反，小团队在前期或者野蛮生长时期，不宜选择微服务，不但影响效率还带来额外的复杂度。成长型或者大公司，有成熟的流程、规范、基础设施、平台等，要想在整条交付链路上加速，就需要投入更多的资源保障微服务化，一切自动化了，能治理了，回头看来这一切就都是值得的，远期收益非常可观。--------------------------------------------------------今天看到这个是这么回事，去小公司就是这样，不要把大公司的技术架构去折腾。
-
发表了文章 2017-08-15
使用nginx搭建rtmp服务器
一、软件需求 1、nginx源码包 下载地址：http://nginx.org/。笔者下载的是1.10.3。 2、pcre源码包。这是一个正则表达式库。nginx会用到这个开源库来做正则匹配。很多软件都会引用，比如php引擎编译的时候也会用到。 下载地址：https://ftp.pcre.org/pub/pcre/pcre-8.36.zip 3、nginx-rtmp-module源码包 这才rtmp服务真正要的工具。 下载地址：https://github.com/arut/nginx-rtmp-module 4、openssl源码包。这个不是必须。只有nginx 版本在1.3.14 - 1.5.0之间的，才需要安装。nginx-rtmp-module的文档特意提到了这点。 在编译nginx的时候，加上参数--with-http_ssl_module。如：./configure --add-module=rtmp模块的源码位置 --with-http_ssl_module 5、推流客户端工具：ffmpeg。Ffmpeg工具下载官网：http://www.ffmpeg.org/download.html 6、拉流播放工具：需要一个很常用的流媒体播放工具VLC。下载地址：http://www.videolan.org/vlc/ 二、编译nginx 解压nginx。进入到nginx源码目录，执行如下命令： 第一步： ./configure --prefix=nginx安装到哪个目录 --with-pcre=pcre库的源码目录,注意是源码目录 --add-module=rtmp模块的源码目录 注：预先将pcre库、rtmp模块解压。以便上面使用。 一般两种压缩包。命令不同，如下： tar.gz包命令：tax -xzvf 软件包 zip包：unzip 软件包 第二步： make && make install 三、配置nginx 配置nginx.conf，增加rtmp与http是同级别的，内容如下： user root; worker_processes 1; #error_log logs/error.log; #error_log logs/error.log notice; error_log logs/error.log error; pid logs/nginx.pid; events { worker_connections 1024; } #服务于rtmp协议的请求 rtmp://开头 rtmp{ server{ listen 1395; chunk_size 4096; #自定义的直播名称,路径中将会用到 #rtmp://192.168.56.88:1395/my_live/rtmpstream中的my_live就是下面定义的名称 application my_live{ #开启直播功能 live on; #接收的rtmp视频流是否落地存储到flv文件，不开启就直接在内存中,存储也是一个视频拆成很多小flv文件 record all; #存储路径 record_path /tmp/nginx_rtmp_av; record_max_size 128K; #为同一个视频文件的视频分片加时间戳 record_unique on; } #hls协议,一样是一个application后面接着自定义名称,区别是hls on; application hls { live on; #开启hls hls on; #hls的视频分片文件(.ts)存放路径 hls_path /tmp/nginx_hls_av; #每个视频分片文件包含多少秒 hls_fragment 5s; #是否清理掉旧的ts文件。默认是开启的。现在关闭 hls_cleanup off; hls_playlist_length 5h; } } #这里可以加其他server侦听其他端口 } #服务于http请求 http{ } 注：nginx-rtmp-module在nignx.conf中使用的指令有很多，需要慢慢消化。先搭建一个简单的骨架。比如还可以进行hls协议的服务。 使用指令的说明文档：https://github.com/arut/nginx-rtmp-module/wiki/Directives 四、推流和拉流 怎么推流 使用ffmpeg工具来推流。Ffmpeg是一套开源的库：视频采集功能、视频格式转换、视频抓图、给视频加水印。很多软件引入了这个库来完成视频的采集、转码。 命令格式如下： ffmpeg -re -i E:\test.mp4 -f flv rtmp://192.168.56.88:1395/my_live/rtmpstream 上述命令，就会读取-i参数指定的视频文件，推流到指定地址去。需要将ffmpeg添加到环境变量中去。或者直接输入ffmpeg的完整安装路径来执行也是可以的。 其中，my_live是nginx.conf中配置的直播名称。rtmpstream是自定义的名称。后续拉流的时候，就必须使用这个名称来拉流，nginx-rtmp落地存储数据(若开启了)的时候，就是使用这个名称命名flv文件的。如一个视频文件才服务器磁盘上被拆成了:rtmpstream-1502794875.flv、rtmpstream-1502794879.flv、rtmpstream-1502794885.flv.................。 -r设定帧速率，默认为25。 -i 设定输入流，也就是读取哪个文件推流到服务端。 运行命令后，会在命令行看到推流过程： 客户端使用ffmpeg完成视频的推流，接着可以在另外一端，输入拉流地址，拉流观看视频。 怎么拉流观看视频 需要一个很常用的流媒体工具：VLC。 软件安装好后(笔者安装的是window下VLC工具)，打开软件，选择"打开网络串流"，如下所示: 输入拉流的地址，推流和拉流都是同一个地址(说的是rtmp协议)。如：rtmp://192.168.56.88:1395/my_live/rtmpstream 到此，完成了，一边推流，一边拉流的效果。 特别注意： 使用hls方式来推流给nginx，客户端ffmpeg的参数要不一样了：需要增加两个参数-vcodec copy和-acodec copy。如果没有这两个参数，是不会把视频落地到hls对应的目录去的。 如下： ffmpeg -re -i E:\test.mp4 -vcodec copy -acodec copy -f flv rtmp://192.168.56.88:1395/hls/hls_stream -acodec表示音频编码，copy表示不改变编解码器，只是改封装器。 -vcodec表示视频编码，copy表示不改变编解码器，只是改封装器。
-
发表了文章 2017-07-09
代码文件的编码不统一导致的坑
联想到discuz，ecshop发布一个新版本的系统给大家使用，会提供utf-8，gb2312版本的代码下载。所以肯定是批量转换编码出来的。 这种是转换html文件。 http://blog.csdn.net/iseagold/article/details/5472377 我需要找一个批量转换文件编码的工具才行。 问题在于：目录中混合了gb2312和utf8编码的。如何才能用工具去自动判断呢。 不要强制转换一次编码。 gb2312和utf8编码的。如果是utf8编码的文件，就不要转换，如果是gb2312的编码才执行转换成utf8编码。 http://blog.csdn.net/liu_qiqi/article/details/38706497 按照给定的字符集存储文件时，在文件的最开头的三个字节中就有可能存储着编码信息，所以，基本的原理就是只要读出文件前三个字节，判定这些字节的值，就可以得知其编码的格式。其实，如果项目运行的平台就是中文操作系统，如果这些文本文件在项目内产生，即开发人员可以控制文本的编码格式，只要判定两种常见的编码就可以 了：GBK和UTF-8。由于中文Windows默认的编码是GBK，所以一般只要判定UTF-8编码格式。 对于UTF-8编码格式的文本文件，其前3个字节的值就是-17、-69、-65，所以，判定是否是UTF-8编码格式的代码片段如下： php的mb_detect_encoding函数，我正准备试一试：function characet($data){ if( !empty($data) ){ $filetype = mb_detect_encoding($data , array('utf-8','gbk','latin1','big5')) ; if( $filetype != 'utf-8'){ $data = mb_convert_encoding($data ,'utf-8' , $filetype); } } return $data; } http://blog.csdn.net/wydycrtd/article/details/4793124 有人也说了，重新认识一下此问题，当时版主回复的时候我就觉得mb函数里一定有这样的功能，但今日研究了mb库，并没有这样的功能。用mb_detect_encoding总是不准确。 mbstring 当前实现了以下编码检测筛选器。 如有以下编码列表的无效字节序列，编码的检测将会失败。 UTF-8, UTF-7, ASCII, EUC-JP,SJIS, eucJP-win, SJIS-win, JIS, ISO-2022-JP var_dump(mb_detect_encoding($str,array('UTF-8','GB2312'))); EUC-CN EUC-CN是GB2312最常用的表示方法。浏览器编码表上的“GB2312”，通常都是指“EUC-CN”表示法。 php中用mb_detect_encoding测出来的euc-cn是gb2312编码:EUC-CN是GB2312最常用的表示方法 GB 2312字元使用两个字节来表示。 “第一位字节”使用0xA1-0xFE “第二位字节”使用0xA1-0xFE 网上找到的不能解决自动检测编码的问题，这里我根据自己需要。检测两种编码就可以了：gb2312和utf-8 <?php header("Content-type: text/html; charset=utf-8"); /* * +--------------------------------------------------- * 遍历指定目录,形成一个目录句柄返回 * +--------------------------------------------------- * * +--------------------------------------------------- */ function explorer_dir($sDir) { static $aTempArr = array(); $dp = opendir($sDir); while ($sFileName = readdir($dp)) { if ($sFileName != '.' && $sFileName != '..') { $sPath = $sDir . "/" . $sFileName; if (is_dir($sPath)) { explorer_dir($sPath); } else { // $filetime=date("Y-m-d H:i:s",filectime("$path")); // $fp=$path.",".$filetime; $fp = $sPath; $aTempArr[] = $fp; } } } closedir($dp); return $aTempArr; } /* * +---------------------------------------------------------------------- * //搜索指定目录下的gb2312编码文件,转换成utf-8编码文件 * +---------------------------------------------------------------------- */ function change_gb2312_to_utf8_dir($dir) { $all_dirs = explorer_dir($dir); $suffix_list = array('php', 'htm', 'html', 'txt', 'js'); echo 'get files count:'; echo count($all_dirs) . '<br />'; $i = 0; foreach ($all_dirs as $dir_key => $file_path) { $file_content = file_get_contents($file_path); $i++; echo $i . '、' . $file_path.'<br />'; var_dump($file_encode_type = mb_detect_encoding($file_content, array('UTF-8', 'EUC-CN'), true)); //EUC-CN是gb2312的另外称呼,php这个扩展返回的是值,不是gb2312 echo '<br />'; //获取文件的后缀,指定文件类型采取做操作，比如图片就不能去修改的 $file_name = basename($file_path); $suffix = get_file_suffix($file_name); if (in_array($suffix, $suffix_list)) { if ($file_encode_type == 'EUC-CN') { echo '<font color="red">had changed the file from ' . $file_encode_type . '(gb2312) to UTF-8:' . $file_path . '</font><br /><br />'; //就是gb2312编码的 $after_change_encode_content = iconv("gb2312", "UTF-8", $file_content); unlink($file_path); file_put_contents($file_path, $after_change_encode_content); unset($after_change_encode_content); } } else { echo '<font color="red">the file not in allow file type:' . $file_path . '</font><br /><br />'; } unset($file_content); echo '--------------------------------------------------------------------<br /><br />'; } } /* * +---------------------------------------------------------------------- * //搜索指定目录下指定编码的文件,目的就是帮助我们看出自己的项目哪些是什么编码的文件 * +---------------------------------------------------------------------- */ function dir_file_encode_list($dir) { $all_dirs = explorer_dir($dir); echo 'get files count:'; echo count($all_dirs) . '<br />'; $i = 0; foreach ($all_dirs as $dir_key => $file_path) { $file_content = file_get_contents($file_path); $i++; echo $i . '、' . $file_path.'<br />'; var_dump($file_encode_type = mb_detect_encoding($file_content, array('UTF-8', 'EUC-CN'), true)); //EUC-CN是gb2312的另外称呼,php这个扩展返回的是值,不是gb2312 echo '<br />'; unset($file_content); echo '--------------------------------------------------------------------<br /><br />'; } } /* * +---------------------------------------------------------------------- * 扫描指定目录下的指定目录下的html文件,批量将里面的 * <meta http-equiv="Content-Type" content="text/html; charset=gbk" /> * 指定的编码替换成另外一个编码 * +---------------------------------------------------------------------- */ function replace_html_charset($dir) { $all_dirs = explorer_dir($dir); $suffix_list = array('htm', 'html','php'); echo 'get files count:'; echo count($all_dirs) . '<br />'; $i = 0; $charset = '<meta http-equiv="Content-Type" content="text/html; charset=gbk" />'; $to_charset = '<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />'; foreach ($all_dirs as $dir_key => $file_path) { $file_content = file_get_contents($file_path); $i++; echo $i . '、' . $file_path.'<br />'; //获取文件的后缀,指定文件类型采取做操作，比如图片就不能去修改的 $file_name = basename($file_path); $suffix = get_file_suffix($file_name); if (in_array($suffix, $suffix_list)) { $patten = '%' . $charset . '%i'; if (preg_match($patten, $file_content)) { $after_change_encode_content = str_ireplace($charset, $to_charset, $file_content); unlink($file_path); file_put_contents($file_path, $after_change_encode_content); unset($after_change_encode_content); echo 'find limit :' . $file_path . '<br /><br />'; } }else{ echo '<font color="red">the file not in allow file type:' . $file_path . '</font><br /><br />'; } } } //dir_file_encode_list("D:\\static\\develop\\mama\\test_change_encode"); //change_gb2312_to_utf8_dir("D:\\static\\develop\\mama\\test_change_encode"); //replace_html_charset("D:\\static\\develop\\mama\\test_change_encode"); function get_file_suffix($file_name){ $file_name_arr = explode(".", $file_name); $suffix = array_pop($file_name_arr); return $suffix; } View Code
-
发表了文章 2017-07-06
mysql分区方案的研究
笔者觉得，分库分表确实好的。但是，动不动搞分库分表，太麻烦了。分库分表虽然是提高数据库性能的常规办法，但是太麻烦了。所以，尝试研究mysql的分区到底如何。 之前写过一篇文章，http://www.cnblogs.com/wangtao_20/p/7115962.html 讨论过订单表的分库分表，折腾起来工作量挺大的，需要多少技术去折腾。做过的人才知道有多麻烦 要按照什么字段切分，切分数据后，要迁移数据;分库分表后，会涉及到跨库、跨表查询，为了解决查询问题，又得用其他方案来弥补(比如为了应对查询得做用户订单关系索引表)。工作量确实不小。 从网上也可以看到，大部分实施过的人(成功的)的经验总结：水平分表，不是必须的，能不做，尽量不做。 像阿里这些系统，数据库单表数量十多亿，达到瓶颈了，不得不做分库分表，扩容也方便。没有选择。 那么，针对起步阶段的业务，技术人员不够，产品还处在试错阶段。是不是可以考虑一下分区方案。 笔者几年前，也犯了思维错误，在小公司做系统，产品还在开发，有待推向市场验证。那个时候，笔者就去考虑什么评论表数据量大的情况下要怎么做，其实伤脑，又费时间，业务没有做起来，其实没多少用处。 架构是演变出来的，不是设计出来的。企图一开始就设计大炮，结果只有蚊子。笔者做试验看看mysql的分区到底是什么个原理。研究发现，其实跟分表差不多，比如按hash打散数据、按值范围分散数据。 一、探讨分区的原理 了解分区到底在做什么，存储的数据文件有什么变化，这样知道分区是怎么提高性能的。 实际上：每个分区都有自己独立的数据、索引文件的存放目录。本质上，一个分区，实际上对应的是一个磁盘文件。所以分区越多，文件数越多。 现在使用innodb存储较多，mysql默认的存储引擎从mysiam变为了innodb了。 以innodb来讨论： innodb存储引擎一张表，对应两个文件：表名.ibd、表名.frm。 如果分区后，一个分区就单独一个ibd文件，如下图： 将fs_punch_in_log表拆分成4个分区，上图中看到，每个分区就变成一个单独的数据文件了。mysql会使用"#p#p1"来命名数据文件，1是分区的编号。总共4个分区，最大值是4。 分表的原理，实际上类似，一个表对应一个数据文件。分表后，数据分散到多个文件去了。性能就提高了。 分区后的查询语句 语句还是按照原来的使用。但为了提高性能。还是尽量避免跨越多个分区匹配数据。 如下图，由于表是按照id字段分区的。数据分散在多个分区。现在使用user_id作为条件去查询。mysql不知道到底分配在哪个分区。所以要去全部分区扫描，如果每个分区的数据量大，这样就耗时很长了。 分区思路和分区语句 id字段的值范围来分区：在1-2千万分到p0分区，4千万到-6千万p1分区。6千万到8千万p2分区。依此推算下去。这样可以分成很多的分区了。 为了保持线性扩容方便。那么只能使用range范围来算了。 sql如下 CREATE TABLE `fs_punch_in_log` ( `id` bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键自增' , `user_id` varchar(50) CHARACTER SET utf8 COLLATE utf8_general_ci NULL DEFAULT NULL COMMENT '签到的用户id' , `punch_in_time` int(10) UNSIGNED NULL DEFAULT NULL COMMENT '打卡签到时间戳' , PRIMARY KEY (`id`) ) partition BY RANGE (id) ( PARTITION p1 VALUES LESS THAN (40000000), PARTITION p2 VALUES LESS THAN (80000000), PARTITION p3 VALUES LESS THAN (120000000), PARTITION p4 VALUES LESS THAN MAXVALUE ); 以上语句经过笔者测验，注意点： 按照hash均匀分散。传递给分区的hash()函数的值，必须是一个整数(hash计算整数计算，实现均匀分布）。上面的id字段就是表的主键，满足整数要求。 partition BY RANGE 中的partition BY表示按什么方式分区。RANGE告诉mysql，我使用范围分区。 情况：如果表结构已经定义好了，里面有数据了，怎么进行分区呢？使用alter语句修改即可，经过笔者测验了。 ALTER TABLE `fs_punch_in_log` PARTITION BY RANGE (id) ( PARTITION p1 VALUES LESS THAN (40000000), PARTITION p2 VALUES LESS THAN (80000000), PARTITION p3 VALUES LESS THAN (120000000), PARTITION p4 VALUES LESS THAN MAXVALUE ) 注：由于表里面已经存在数据了，进行重新分区，mysql会把数据按照分区规则重新移动一次，生成新的文件。如果数据量比较大，耗时间比较长。 二、四种分区类型 mysql分区包括四种分区方式：hash分区、按range分区、按key分区、list分区。 四种有点多，实际上，为了好记，把类再缩小点，就两大类方式进行分区：一种是计算hash值、一种是按照范围值。 其实分库分表的时候，也会用到两大类，hash运算分、按值范围分。 1、HASH分区 有常规hash和线性hash两种方式。 常规hash是基于分区个数取模（%）运算。根据余数插入到指定的分区。打算分4个分区，根据id字段来分区。 怎么算出新插入一行数据，需要放到分区1，还是分区4呢? id的值除以4，余下1，这一行数据就分到1分区。 常规hash，可以让数据非常平均的分布每一个分区。比如分为4个取，取余数，余数总是0-3之间的值(总到这几个分区去)。分配打散比较均匀。 但是也是有缺点的：由于分区的规则在创建表的时候已经固定了，数据就已经打散到各个分区。现在如果需要新增分区、减少分区，运算规则变化了，原来已经入库的数据，就需要适应新的运算规则来做迁移。 实际上在分库分表的时候，使用hash方式，也是数据量迁移的问题。不过还好。 针对这个情况，增加了线性hash的方式。 线性HASH(LINEAR HASH)稍微不同点。 实际上线性hash算法，就是我们memcache接触到的那种一致性hash算法。使用虚拟节点的方式，解决了上面hash方式分区时，当新增加分区后，涉及到的数据需要大量迁移的问题。也不是不需要迁移，而是需要迁移的数据量小。 在技术实现上：线性哈希功能使用的一个线性的2的幂（powers-of-two）运算法则，而常规哈希使用的是求哈希函数值的模数。 线性哈希分区和常规哈希分区在语法上的唯一区别在于，在“PARTITION BY”子句中添加“LINEAR”关键字。 两者也有有相同的地方： 都是均匀分布的，预先指定n个分区，然后均匀网几个分区上面分布数据。根据一个字段值取hash值，这样得到的结果是一个均匀分布的值。后面添加新的分区多少需要考虑数据迁移。 常规HASH和线性HASH，因为都是计算整数取余的方式，那么增加和收缩分区后，原来的数据会根据现有的分区数量重新分布。 HASH分区不能删除分区，所以不能使用DROP PARTITION操作进行分区删除操作； 考虑以后迁移数据量少，使用线性hash。 2、按照range范围分区 范围分区，可以自由指定范围。比如指定1-2000是一个分区，2000到5000千又是一个分区。范围完全可以自己定。后面我要添加新的分区，很容易吗? 3、按key分区 类似于按HASH分区，区别在于KEY分区只支持计算一列或多列，且MySQL服务器提供其自身的哈希函数。必须有一列或多列包含整数值。 4、按list方式分区 可以把list看成是在range方式的基础上的改进版。list和range本质都是基于范围，自己控制范围。 range是列出范围，比如1-2000范围算一个分区，这样是一个连续的值。 而list分区方式是枚举方式。可以指定在1,5,8,9,20这些值都分在第一个分区。从list单词的字面意思命名暗示就是列表，指定列表中出现的值都分配在第几个分区。 三、如何根据业务选择分区类型 1、何时选择分区,何时选择分表 分表还是比分区更加灵活。在代码中可以自己控制。一般分表会与分库结合起来使用的。在进行分表的时候，顺带连分库方案也一起搞定了。 分表分库，性能和并发能力要比分区要强。分表后，有个麻烦点：自己需要修改代码去不同的表操作数据。 比如用户表分表后，计划分4个表，每个表4千万用户。按照用户编号取模为4。代码很多处要做专门的匹配如下： 每次操作用户资料，先要根据uid算出是哪个表名称。然后再去写sql查询。 当然，是可以使用数据库中间件来做完成分库、分表。应用代码不用修改。大部分中间件是根据他们自己的业务特点定制的，拿来使用，不见得适合自己的业务。所以目前缺少通用的。 如果使用分区的方式。代码不用修改。sql还是按照原来的方式写。mysql内部自动做了匹配了。 非常适合业务刚刚起步的时候，能不能做起来，存活期是多久不知。不用把太多精力花费在分库分表的适应上。 考虑到现在业务才起步，使用分区不失为一种既省事又能提高数据库并发能力的办法。等以后业务发展起来了，数据量过亿了，那个时候经济实力已增强，再做改进方案不迟。 架构是演变出来的，不是设计出来的。适应当前业务的方案，就是好的方案。 过度设计也是一种负担：很多技术，企图一开始就设计出一个多大量的系统，实际上没有那种量，为了显示自己技术牛逼。 总结：访问量不大，但是数据表行数很多。可以使用分区的方式。访问量大，数据量大，可以重构成分表的方式。 这是因为虽然数据量多，但是访问量不大，如果使用分表的话，要修改代码很多地方，弄起来太麻烦了。投入多，产出少就没必要了。 2、如何选择适合自己的分区类型 使用分区和分表一样的思想：尽量让数据均匀分散，这样达到分流、压力减小的效果。如果不能均匀分布，某个分区的操作量特别大，出现单点瓶颈。 虽然4种类型的分区方式。其实总共两大类，按范围分区和按hash运算分区。 range范围分区，适合按照范围来切分数据。比如按时间范围分区。 hash，适合均匀分散数据。使用hash分区，麻烦点是后续增加分区，数据要迁移。有了线性hash分区法，这个迁移量减低了很多。 以用户表为例子，如果要使用分区方案。改使用哪种分区类型呢？ 考虑到user_id一般不会设计成自增数字。有人会奇怪，怎么不是自增的，我见过好多用户编号都是自增的！ 的确，有自增数字做uid的，不过一般是开源系统为了省事，比如discuz、ecshop等。人家没那么多工作量给你设计用户编号方案。 自增的用户编号，由于是每次加1进行递增的。这规律太明显了，很容易被别有用途的人猜测user_id。再说，别人一看就知道你有多少用户! 有个原则，设计编号的时候，尽量不要让外部知道你的生成规律。比如订单号，如果是逐个加1的订单号，外界可以猜测出你的业务订单总数出来。 说一个自增用户编号的例子。笔者曾经在一家上市互联网公司，有几千万的用户，uid过去是discuz那一套自增的方式。后来不得不改掉user_id的生成方式。笔者当时负责了这个改造方案。 不是自增的数字，会是这种：注册一个是1897996，再注册一个是9689898，外界完全找不到数字的规律。 不是自增的编号，如果使用范围来分区，各个分区的数据做不到均匀分布的。原因如下： 比如说用户编号为1-200000000的用户分配到p1分区，20000000-40000000分配到p2分区，40000000-60000000分配到p3区，这样类推下去。 由于用户编号不是自增，注册分配到的用户编号，可能是1到2千万之间的数字，也可能是4千万到6千万之间的一个数字。如果被分配到4千万到6千万的数字会更多，那么各个分区给到的数据是不均匀的。 故不好使用范围来分区。 比较好的办法是，使用hash取模，user_id%分区数。数据就可以分散均匀到4个分区去了。
-
发表了文章 2017-07-04
订单表的分库分表方案设计(大数据)
原创文章，转载注明出处 一、两种方案分库分表 一般业界，对订单数据的分库分表，笔者了解，有两类思路：按照订单号来切分、按照用户id来切分。 方案一、按照订单号来做hash分散订单数据 把订单号看作是一个字符串，做hash，分散到多个服务器去。 具体到哪个库、哪个表存储数据呢？订单号里面的数字来记录着。 现在的微信红包。它的订单分库分表，是对订单号进行hash计算。不是什么取模、取整数。这样数据是均匀分散的。 然后订单号的末尾3个数，里面是包含了库名称、表名称的。 如果要查询某用户的所有订单呢？ 由于是根据订单号来分散数据的。他的订单分散在了多个库、多个表中。 总不能去所有的库，所有的表扫描吧。这样效率很低。 其实按照uid切分订单，一样会遇到查询的问题。比如要查询a订单的信息。分库分表的规则是按照uid，都不知道数据在哪个库，无从查。 后续说明解决思路。 一般使用方案二的比较多，一个用户的所有订单，都在一张表里面，那么做分页展示的时候，就容易。 方案二、按照用户id打散订单数据。 以uid来切分数据，有两种思路： 一种是，某个范围的uid订单到哪些库。0到2千万uid，对应的订单数据到a库、a表。2千万到4千万对应的订单到b库。 为什么这种方案用得比较少呢？ 容易出现瓶颈吗。某个范围内的用户，下单量比较多，那么造成这个库的压力特别大。其他库却没什么压力。 第二种是，使用uid取模运算。第二种方案业界用得比较多。 一方面、处理简单，程序上做取模运算就好了。 另一方面、使用取模的方式，数据比较均匀分散到多个库去了。不容易出现单个库性能瓶颈。 但是不好处也有：即要扩容的时候，比较麻烦。就需要迁移数据了。 要扩容的时候，为了减少迁移的数据量，一般扩容是以倍数的形式增加。比如原来是8个库，扩容的时候，就要增加到16个库，再次扩容，就增加到32个库。这样迁移的数据量，就小很多了。这个问题不算很大问题，毕竟一次扩容，可以保证比较长的时间，而且使用倍数增加的方式，已经减少了数据迁移量。 下面笔者，分析一下按照用户id取模的方式分库分表。 按照用户id作为key来切分订单数据，具体如下： 1、 库名称定位：用户id末尾4位 Mod 32。 Mod表示除以一个数后，取余下的数。比如除以32后，余下8，余数就是8。 代码符号是用%表示：15%4=3。 2、表名称定位：（用户id末尾4位 Dev 32） Mod 32。 Dev表示除以一个数，取结果的整数。比如得到结果是25.6，取整就是25。 代码用/来表示：$get_int = floor(15/4)。15除以4，是一个小数3.75，向下取整就是3。一定是向下取整，向上取整就变成了4了。 按照上面的规则：总共可以表示多少张表呢？32个库*每个库32个表=1024张表。如果想表的数量小，就把32改小一些。 上面是用计算机术语来表示， 下面用通俗的话描述。 1、库名称计算 用户id的后4位数，取32的模(取模就是除以这个数后，余多少)。余下的数，是0-31之间。 这样可以表示从0-31之间，总共32个数字。用这个32个数字代表着32个库名称：order_db_0、order_db_2.........................order_db_31 2、表名称计算 最后要存储定到哪个表名里面去呢？ 用户id的最后4位数，除以32，取整数。将整数除以32，得到余数，能够表示从0-31之间32个数字，表示表名称。 表名称类似这样：order_tb_1、order_tb_2..........................order_tb_31。一个库里面，总共32个表名称。 比如用户id：19408064，用最后4位数字8064除以32，得到是251.9，取它的整数是251。 接着将251除以32，取余数，余数为27。 为了保持性能，每张表的数据量要控制。单表可以维持在一千万-5千万行的数据。1024*一千万。哇，可以表示很多数据了。 三、思考优点和缺点 优点 订单水平分库分表，为什么要按照用户id来切分呢？ 好处：查询指定用户的所有订单，避免了跨库跨表查询。 因为，根据一个用户的id来计算节点，用户的id是规定不变的，那么计算出的值永远是固定的(x库的x表) 那么保存订单的时候，a用户的所有订单，都是在x库x表里面。需要查询a用户所有订单时，就不用进行跨库、跨表去查询了。 缺点 这种方式也不是没有缺点。 缺点在于：数据分散不均匀，某些表的数据量特别大，某些表的数据量很小。因为某些用户下单量多，打个比方，1000-2000这个范围内的用户，下单特别多， 而他们的id根据计算规则，都是分到了x库x表。造成这个表的数据量大，单表的数据量撑到极限后，咋办呢? 总结一下：每种分库分表方案也不是十全十美，都是有利有弊的。目前来说，这种使用用户id来切分订单数据的方案，还是被大部分公司给使用。实际效果还不错。程序员省事，至于数据量暴涨，以后再说呢。毕竟公司业务发展到什么程度，不知道的，项目存活期多久，未来不确定。先扛住再说。 比较好的方案是不是：又能均匀分散、又能避免单表数据量暴涨方便扩容。以前看过一篇文章介绍过使用节点来存储分库分表。笔者暂时没完整的思路。 二、查询需求的考虑 方案一的查询问题 方案一的情况下，由于是按照订单号做分散数据到多个库、多个表。如果需要查询a用户的所有订单，咋办？需要跨库、跨表查询。 这样效率低。不可行。 方案二的查询问题 如果是按照uid来切分订单数据，在实际应用中一些很频繁的查询需求像下面这样： 1、后台、前台，往往是输入一个订单号，查询这个订单的数据。select操作 2、然后修改这个订单的相关状态。update操作。 由于是，按照用户编号将订单数据分散在各个库、各个表中。 那输入订单号，怎么知道去哪个库、哪个表查询呢？不可能所有的库、所有表都查询一遍，效率太低，不可行。 三、解决办法：建立用户id和订单号的索引关系表 无论是根据用户id来切分订单，还是根据订单号切分数据。总不能十全十美的。 写到这里，发现真的没有一种技术方案是十全十美的，看，使用用户id来切分订单，好处是有了，坏处也出来了。 不过没关系，早要有心里承受：不要觉得技术是完美无缺的。针对这种情况，想办法去解决办法。 思路：既然是根据订单号分散订单数据，如果需要知道某个用户所有的订单。只要我能知道了a用户的所有的订单号，那么就可以根据订单号定位到表名称了。 思路：既然是根据用户id来分散订单数据的。那么只要知道了这个订单号是谁的(得到了用户id)，就能知道去哪个库、哪个表查询数据了。 那怎么知道是谁的呢？建立一个索引关系表，暂且叫做订单用户关系索引表order_user_idx。咱们命名为了保持维护性，还是一看能够知道是干嘛用的。 存储的数据包括两项：订单号、用户编号。 这样输入订单号，可以去查询索引关系表，获取到用户编号。 得到了用户编号，问题解决了。订单信息是根据用户编号分库分表的，可以直接定位到x库x表了。 当创建订单的时候，就要把关系插入到表里面去了。保存关系记录时，为了减低用户等待时间，不需要实时，做成异步。加入到消息队列中去操作。 订单用户索引关系表的性能优化 考虑到，一个用户的下的订单可能是几十个，也可能是几百个，随着时间的推移，会越来越多。这个索引关系表，也不能使用单表存储。 所以对这个订单用户关系索引表，也要进行分库分表：直接根据订单号取模进行分库分表。是不是感觉挺麻烦了。确实麻烦。不过能解决问题就好。暂时没想到其他办法了。 一个订单，在创建的时候，就已经分配好给指定用户了。只是一个关系对应，以后也不会变化。 根据这个特点。订单用户索引关系表，其实可以放到内存中缓存起来应对查询需求(数据库那张索引关系表也要有，数据要持久化)。 平时查询的时候，走内存缓存查询。如果查询不到，再走数据库查询一下关系。这样速度就很快了。 结语：水平分表，其实折腾起来工作量挺大的，切分了后，出现新的问题，代码查询又得改，要提供其他解决办法。所以经常看到别人说，能不水平分表，尽量不要分，业务没达到瓶颈，先用硬件扛住，后面再考虑水平切分数据。看银行、联通这些有钱的企业，使用性能强劲的oracle搭配小型机服务器，单表的数据量达到十多亿。小型机是专门定制的，几十万一台。性能很强。分库分表是很耗费时间、当你交易量做到上亿规模的时候，那时，公司的实力应该可以了，经济方面有足够的实力聘请经验丰富的技术来重构。 思考一、b2b平台的订单分卖家和买家的时候，选择什么字段来分库分表呢？ 上面讨论的情况是，b2c平台。订单的卖家就一个，就是平台自己。 b2b平台，上面支持开店，买家和卖家都要能够登陆看到自己的订单。 先来看看，分表使用买家id分库分表和根据卖家id分库分表，两种办法出现的问题 如果按买家id来分库分表。有卖家的商品，会有n个用户购买，他所有的订单，会分散到多个库多个表中去了，卖家查询自己的所有订单，跨库、跨表扫描，性能低下。 如果按卖家id分库分表。买家会在n个店铺下单。订单就会分散在多个库、多个表中。买家查询自己所有订单，同样要去所有的库、所有的表搜索，性能低下。 所以，无论是按照买家id切分订单表，还是按照卖家id切分订单表。两边都不讨好。 淘宝的做法是拆分买家库和卖家库，也就是两个库：买家库、卖家库。 买家库，按照用户的id来分库分表。卖家库，按照卖家的id来分库分表。 实际上是通过数据冗余解决的：一个订单，在买家库里面有，在卖家库里面也存储了一份。下订单的时候，要写两份数据。先把订单写入买家库里面去，然后通过消息中间件来同步订单数据到卖家库里面去。 买家库的订单a修改了后，要发异步消息，通知到卖家库去，更改状态。 思考二：那可以按订单号来分库分表吗? 这样分库分表的话，用户有10个订单，订单不见得都在一个库、一个表里面。查询a用户的所有订单，就会变得麻烦了。尤其是要进行分页展示，分散在不同的表，甚至不同的数据库服务器，也比较耗费性能。 那么订单号里面，最好是要有分库分表信息。淘宝的是在订单号里面添加了卖家id末2位、买家id末2位。这样的好处是干嘛呢？直接定位到具体的库、具体的表去了？ 怎么根据这个呢。因为分库、分表的规则，买家库是按照卖家id末尾2位数分，卖家库是按照卖家id末尾两位分。 所以，只要从订单号里面拿到了这些数字信息，就知道在哪个库，哪个表了。 这种办法，与微信的红包订单号是类似的，末尾三位数包含了库信息、表信息。 按照这样，其实就没必要使用订单号来计算了？ 如果是按照用户id的后4位数取模分散订单数据。那么订单号的生成，可以在后面加上用户id的后4位数。 那么，虽然是按照用户id来对订单表分库分表的。其实可以直接根据订单号，知道这个订单在哪个库哪个表了。 如果是b2b系统，涉及到卖家和买家。那么可以把卖家和买家的id后面4位都加进去。不过是不是订单号太长了？ 思考三、按照订单的时间来分表如何? 一月一张表。一年一张表。用户的所有订单，会分散在不同的库、不同的表中。 按照时间分，在切分订单数据的时候，业界用得比较少。 出现如下两个问题： 1、如果需要分页查询某个用户的所有订单数据，就会出现跨库、跨表查询。效率低。 可以做折中：限制只能查一个范围内的订单，比如一次只能查询，一年以内或者一个月以内的订单。 2、某个时间集中写入数据，出现瓶颈。如一个月一张表。这个月的订单量暴涨呢。那么写入新的订单数据都会操作这张表。造成性能低下。影响整个业务系统交易。 真正好的分表方案，尽量将写数据分散到多个表去，达到分流效果，系统的并发能力就提高了。
滑动查看更多
暂无更多信息
-
发表了文章
2010-12-05
收藏好文章 PHP函数的实现原理
-
发表了文章
2010-12-29
js开发积累
-
发表了文章
2010-12-31
php不设置脚本执行时间的方法
-
发表了文章
2010-12-31
SQL编写总结
-
发表了文章
2011-01-01
再次理解js中的call函数
-
发表了文章
2011-01-01
js代码定义类代码的领悟
-
发表了文章
2011-01-09
遇到mysql数据表不存在的问题
-
发表了文章
2011-01-16
include、ruquire使用相对路径总结
-
发表了文章
2011-01-21
php中未定义的变量使用技巧
-
发表了文章
2011-01-21
阅读<php程序设计>笔记
-
发表了文章
2011-01-21
头信息已输出的报错信息位置定位
-
发表了文章
2011-01-21
数据库设计字段类型设置经验
-
发表了文章
2011-02-03
mysql replace into语句学习
-
发表了文章
2011-02-16
php获取输入流
-
发表了文章
2011-02-20
js操作的跨域问题:js实现自动设置框架载入页面高度的问题
-
发表了文章
2011-02-20
插入数据sql使用“insert into set”形式的理解
-
发表了文章
2011-02-21
mysql变量使用总结
-
发表了文章
2011-02-22
get方式传递参数问题解决经验
-
发表了文章
2011-02-22
mysql优化学习
-
发表了文章
2011-02-22
insert 语句后面的一些参数使用知识
滑动查看更多
暂无更多信息