架构|存储

架构|存储

MySQL主从同步那点事儿

数据库Rock 发表了文章 • 0 个评论 • 158 次浏览 • 2017-09-10 22:06 • 来自相关话题

一、前言​
关于mysql主从同步,相信大家都不陌生,随着系统应用访问量逐渐增大,单台数据库读写访问压力也随之增大,当读写访问达到一定瓶颈时,将数据库的读写效率骤然下降,甚至不可用;为了解决此类问题,通常会采用mysql集群,当主库宕机后,集群会自动将一个从库升级为主库,继续对外提供服务;那么主库和从库之间的数据是如何同步的呢?本文针对MySQL 5.7版本进行下面的分析,下面随笔者一起探究一下mysql主从是如何同步的。
 
二、MySQL主从复制原理
为了减轻主库的压力,应该在系统应用层面做读写分离,写操作走主库,读操作走从库,下图为MySQL官网给出的主从复制的原理图,从图中可以简单的了解读写分离及主从同步的过程,分散了数据库的访问压力,提升整个系统的性能和可用性,降低了大访问量引发数据库宕机的故障率。




 
三、binlog简介
MySQL主从同步是基于binlog文件主从复制实现,为了更好的理解主从同步过程,这里简单介绍一下binlog日志文件。

binlog日志用于记录所有更新了数据或者已经潜在更新了数据(例如,没有匹配任何行的一个DELETE)的所有语句。语句以“事件”的形式保存,它描述数据更改,它是以二进制的形式保存在磁盘中。我们可以通过mysql提供的查看工具mysqlbinlog查看文件中的内容,例如 mysqlbinlog mysql-bin.00001 | more,这里注意一下binlog文件的后缀名00001,binlog文件大小和个数会不断的增加,当MySQL停止或重启时,会产生一个新的binlog文件,后缀名会按序号递增,例如mysql-bin.00002、mysql-bin.00003,并且当binlog文件大小超过 max_binlog_size系统变量配置时也会产生新的binlog文件。
 
(一)binlog日志格式
(1) statement : 记录每一条更改数据的sql;
优点:binlog文件较小,节约I/O,性能较高。缺点:不是所有的数据更改都会写入binlog文件中,尤其是使用MySQL中的一些特殊函数(如LOAD_FILE()、UUID()等)和一些不确定的语句操作,从而导致主从数据无法复制的问题。
 
(2) row : 不记录sql,只记录每行数据的更改细节
优点:详细的记录了每一行数据的更改细节,这也意味着不会由于使用一些特殊函数或其他情况导致不能复制的问题。缺点:由于row格式记录了每一行数据的更改细节,会产生大量的binlog日志内容,性能不佳,并且会增大主从同步延迟出现的几率。
 
(3) mixed:一般的语句修改使用statment格式保存binlog,如一些函数,statement无法完成主从复制的操作,则采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式,也就是在Statement和Row之间选择一种。
 
(二)binlog日志内容




 
(三)binlog事件类型
MySQL binlog记录的所有操作实际上都有对应的事件类型的,譬如STATEMENT格式中的DML操作对应的是QUERY_EVENT类型,ROW格式下的DML操作对应的是ROWS_EVENT类型,如果想了解更多请参考官方文档,有关binlog日志内容不在这里过多赘述,简单介绍一下是为了更好的理解主从复制的细节,下面我们进入正题。
 
 
四、MySQL主从复制原理
mysql主从复制需要三个线程,master(binlog dump thread)、slave(I/O thread 、SQL thread)。
 
 
Master
(1)binlog dump线程:当主库中有数据更新时,那么主库就会根据按照设置的binlog格式,将此次更新的事件类型写入到主库的binlog文件中,此时主库会创建log dump线程通知slave有数据更新,当I/O线程请求日志内容时,会将此时的binlog名称和当前更新的位置同时传给slave的I/O线程。
 
Slave
(2)I/O线程:该线程会连接到master,向log dump线程请求一份指定binlog文件位置的副本,并将请求回来的binlog存到本地的relay log中,relay log和binlog日志一样也是记录了数据更新的事件,它也是按照递增后缀名的方式,产生多个relay log( host_name-relay-bin.000001)文件,slave会使用一个index文件( host_name-relay-bin.index)来追踪当前正在使用的relay log文件。
 
(3)SQL线程:该线程检测到relay log有更新后,会读取并在本地做redo操作,将发生在主库的事件在本地重新执行一遍,来保证主从数据同步。此外,如果一个relay log文件中的全部事件都执行完毕,那么SQL线程会自动将该relay log 文件删除掉。
 
下面是整个复制过程的原理图:




 
四、主从同步延迟
mysql的主从复制都是单线程的操作,主库对所有DDL和DML产生binlog,binlog是顺序写,所以效率很高,slave的I/O线程到主库取日志,效率也比较高,但是,slave的SQL线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的,不是顺序的,成本高很多,还可能存在slave上的其他查询产生lock争用的情况,由于SQL也是单线程的,所以一个DDL卡住了,需要执行很长一段事件,后续的DDL线程会等待这个DDL执行完毕之后才执行,这就导致了延时。当主库的TPS并发较高时,产生的DDL数量超过slave一个sql线程所能承受的范围,延时就产生了,除此之外,还有可能与slave的大型query语句产生了锁等待导致。
 
由于主从同步延迟是客观存在的,我们只能从我们自己的架构上进行设计, 尽量让主库的DDL快速执行。下面列出几种常见的解决方案:
业务的持久化层的实现采用分库架构,mysql服务可平行扩展,分散压力。服务的基础架构在业务和mysql之间加入memcache或者Redis的cache层。降低mysql的读压力;使用比主库更好的硬件设备作为slave;sync_binlog在slave端设置为0;–logs-slave-updates 从服务器从主服务器接收到的更新不记入它的二进制日志。禁用slave的binlog
 
五、参考资料
https://dev.mysql.com/doc/refman/5.7/en/replication.html  
http://www.linuxidc.com/Linux/2014-05/101450.htm  
http://blog.csdn.net/xiongping_/article/details/49907095  
http://www.cnblogs.com/martinzhang/p/3454358.html  
“本文转载自 linkedkeeper.com (文/张松然)”地址:http://www.linkedkeeper.com/detail/blog.action?bid=1028   查看全部
一、前言​
关于mysql主从同步,相信大家都不陌生,随着系统应用访问量逐渐增大,单台数据库读写访问压力也随之增大,当读写访问达到一定瓶颈时,将数据库的读写效率骤然下降,甚至不可用;为了解决此类问题,通常会采用mysql集群,当主库宕机后,集群会自动将一个从库升级为主库,继续对外提供服务;那么主库和从库之间的数据是如何同步的呢?本文针对MySQL 5.7版本进行下面的分析,下面随笔者一起探究一下mysql主从是如何同步的。
 
二、MySQL主从复制原理
为了减轻主库的压力,应该在系统应用层面做读写分离,写操作走主库,读操作走从库,下图为MySQL官网给出的主从复制的原理图,从图中可以简单的了解读写分离及主从同步的过程,分散了数据库的访问压力,提升整个系统的性能和可用性,降低了大访问量引发数据库宕机的故障率。
mysqlrep.png

 
三、binlog简介
MySQL主从同步是基于binlog文件主从复制实现,为了更好的理解主从同步过程,这里简单介绍一下binlog日志文件。

binlog日志用于记录所有更新了数据或者已经潜在更新了数据(例如,没有匹配任何行的一个DELETE)的所有语句。语句以“事件”的形式保存,它描述数据更改,它是以二进制的形式保存在磁盘中。我们可以通过mysql提供的查看工具mysqlbinlog查看文件中的内容,例如 mysqlbinlog mysql-bin.00001 | more,这里注意一下binlog文件的后缀名00001,binlog文件大小和个数会不断的增加,当MySQL停止或重启时,会产生一个新的binlog文件,后缀名会按序号递增,例如mysql-bin.00002、mysql-bin.00003,并且当binlog文件大小超过 max_binlog_size系统变量配置时也会产生新的binlog文件。
 
(一)binlog日志格式
(1) statement : 记录每一条更改数据的sql;
  • 优点:binlog文件较小,节约I/O,性能较高。
  • 缺点:不是所有的数据更改都会写入binlog文件中,尤其是使用MySQL中的一些特殊函数(如LOAD_FILE()、UUID()等)和一些不确定的语句操作,从而导致主从数据无法复制的问题。

 
(2) row : 不记录sql,只记录每行数据的更改细节
  • 优点:详细的记录了每一行数据的更改细节,这也意味着不会由于使用一些特殊函数或其他情况导致不能复制的问题。
  • 缺点:由于row格式记录了每一行数据的更改细节,会产生大量的binlog日志内容,性能不佳,并且会增大主从同步延迟出现的几率。

 
(3) mixed:一般的语句修改使用statment格式保存binlog,如一些函数,statement无法完成主从复制的操作,则采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式,也就是在Statement和Row之间选择一种。
 
(二)binlog日志内容
binlog.png

 
(三)binlog事件类型
MySQL binlog记录的所有操作实际上都有对应的事件类型的,譬如STATEMENT格式中的DML操作对应的是QUERY_EVENT类型,ROW格式下的DML操作对应的是ROWS_EVENT类型,如果想了解更多请参考官方文档,有关binlog日志内容不在这里过多赘述,简单介绍一下是为了更好的理解主从复制的细节,下面我们进入正题。
 
 
四、MySQL主从复制原理
mysql主从复制需要三个线程,master(binlog dump thread)、slave(I/O thread 、SQL thread)。
 
 
Master
(1)binlog dump线程:当主库中有数据更新时,那么主库就会根据按照设置的binlog格式,将此次更新的事件类型写入到主库的binlog文件中,此时主库会创建log dump线程通知slave有数据更新,当I/O线程请求日志内容时,会将此时的binlog名称和当前更新的位置同时传给slave的I/O线程。
 
Slave
(2)I/O线程:该线程会连接到master,向log dump线程请求一份指定binlog文件位置的副本,并将请求回来的binlog存到本地的relay log中,relay log和binlog日志一样也是记录了数据更新的事件,它也是按照递增后缀名的方式,产生多个relay log( host_name-relay-bin.000001)文件,slave会使用一个index文件( host_name-relay-bin.index)来追踪当前正在使用的relay log文件。
 
(3)SQL线程:该线程检测到relay log有更新后,会读取并在本地做redo操作,将发生在主库的事件在本地重新执行一遍,来保证主从数据同步。此外,如果一个relay log文件中的全部事件都执行完毕,那么SQL线程会自动将该relay log 文件删除掉。
 
下面是整个复制过程的原理图:
mysqlab.png

 
四、主从同步延迟
mysql的主从复制都是单线程的操作,主库对所有DDL和DML产生binlog,binlog是顺序写,所以效率很高,slave的I/O线程到主库取日志,效率也比较高,但是,slave的SQL线程将主库的DDL和DML操作在slave实施。DML和DDL的IO操作是随即的,不是顺序的,成本高很多,还可能存在slave上的其他查询产生lock争用的情况,由于SQL也是单线程的,所以一个DDL卡住了,需要执行很长一段事件,后续的DDL线程会等待这个DDL执行完毕之后才执行,这就导致了延时。当主库的TPS并发较高时,产生的DDL数量超过slave一个sql线程所能承受的范围,延时就产生了,除此之外,还有可能与slave的大型query语句产生了锁等待导致。
 
由于主从同步延迟是客观存在的,我们只能从我们自己的架构上进行设计, 尽量让主库的DDL快速执行。下面列出几种常见的解决方案:
  1. 业务的持久化层的实现采用分库架构,mysql服务可平行扩展,分散压力。
  2. 服务的基础架构在业务和mysql之间加入memcache或者Redis的cache层。降低mysql的读压力;
  3. 使用比主库更好的硬件设备作为slave;
  4. sync_binlog在slave端设置为0;
  5. –logs-slave-updates 从服务器从主服务器接收到的更新不记入它的二进制日志。
  6. 禁用slave的binlog

 
五、参考资料
https://dev.mysql.com/doc/refman/5.7/en/replication.html  
http://www.linuxidc.com/Linux/2014-05/101450.htm  
http://blog.csdn.net/xiongping_/article/details/49907095  
http://www.cnblogs.com/martinzhang/p/3454358.html  
“本文转载自 linkedkeeper.com (文/张松然)”地址:http://www.linkedkeeper.com/detail/blog.action?bid=1028  

MYSQL开发实践8问8答

数据库chris 发表了文章 • 1 个评论 • 150 次浏览 • 2017-08-20 13:59 • 来自相关话题

最近研发的项目对 DB 依赖比较重,梳理了这段时间使用MySQL遇到的8个比较具有代表性的问题,答案也比较偏自己的开发实践,没有 DBA专业和深入,有出入的请使劲拍砖!
 

一、MySQL读写性能是多少,有哪些性能相关的重要参数?​

这里做了几个简单压测实验,结果如下:
机器:8核CPU,8G内存
表结构(尽量模拟业务):12个字段(1个bigint(20)为自增primary key,5个int(11),5个varchar(512),1个timestamp),InnoDB存储引擎。
实验1(写):insert => 6000/s
前提:连接数100,每次insert单条记录
分析:CPU跑了50%,这时磁盘为顺序写,故性能较高实验2(写):update(where条件命中索引) => 200/s
前提:连接数100,10w条记录,每次update单条记录的4个字段(2个int(11),2个varchar(512))
分析:CPU跑2%,瓶颈明显在IO的随机写实验3(读):select(where条件命中索引) => 5000/s
前提:连接数100,10w条记录,每次select单条记录的4个字段(2个int(11),2个varchar(512))
分析:CPU跑6%,瓶颈在IO,和db的cache大小相关实验4(读):select(where条件没命中索引) => 60/s
前提:连接数100,10w条记录,每次select单条记录的4个字段(2个int(11),2个varchar(512))
分析:CPU跑到80%,每次select都需遍历所有记录,看来索引的效果非常明显!几个重要的配置参数,可根据实际的机器和业务特点调整
max_connecttions:最大连接数

table_cache:缓存打开表的数量

key_buffer_size:索引缓存大小

query_cache_size:查询缓存大小

sort_buffer_size:排序缓存大小(会将排序完的数据缓存起来)

read_buffer_size:顺序读缓存大小

read_rnd_buffer_size:某种特定顺序读缓存大小(如order by子句的查询)PS:查看配置方法:show variables like '%max_connecttions%';
 

二、MySQL负载高时,如何找到是由哪些SQL引起的?

方法:慢查询日志分析(MySQLdumpslow)
 
慢查询日志例子,可看到每个慢查询SQL的耗时:
# User@Host: edu_online[edu_online] @ [10.139.10.167]
# Query_time: 1.958000 Lock_time: 0.000021 Rows_sent: 254786 Rows_examined: 254786
SET timestamp=1410883292;
select * from t_online_group_records;日志显示该查询用了1.958秒,返回254786行记录,一共遍历了254786行记录。及具体的时间戳和SQL语句。

使用MySQLdumpslow进行慢查询日志分析:

MySQLdumpslow -s t -t 5 slow_log_20140819.txt输出查询耗时最多的Top5条SQL语句
 
-s:排序方法,t表示按时间 (此外,c为按次数,r为按返回记录数等)
-t:去Top多少条,-t 5表示取前5条
 
执行完分析结果如下:
Count: 1076100 Time=0.09s (99065s) Lock=0.00s (76s) Rows=408.9 (440058825), edu_online[edu_online]@28hosts
select * from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > N
Count: 1076099 Time=0.05s (52340s) Lock=0.00s (91s) Rows=62.6 (67324907), edu_online[edu_online]@28hosts
select * from t_online_course where UNIX_TIMESTAMP(c_updatetime) > N
Count: 63889 Time=0.78s (49607s) Lock=0.00s (3s) Rows=0.0 (18), edu_online[edu_online]@[10x.213.1xx.1xx]
select f_uin from t_online_student_contact where f_modify_time > N
Count: 1076097 Time=0.02s (16903s) Lock=0.00s (72s) Rows=52.2 (56187090), edu_online[edu_online]@28hosts
select * from t_online_video_info where UNIX_TIMESTAMP(v_update_time) > N
Count: 330046 Time=0.02s (6822s) Lock=0.00s (45s) Rows=0.0 (2302), edu_online[edu_online]@4hosts
select uin,cid,is_canceled,unix_timestamp(end_time) as endtime,unix_timestamp(update_time) as updatetime
from t_kick_log where unix_timestamp(update_time) > N以第1条为例,表示这类SQL(N可以取很多值,这里MySQLdumpslow会归并起来)在8月19号的慢查询日志内出现了1076100次,总耗时99065秒,总返回440058825行记录,有28个客户端IP用到。

通过慢查询日志分析,就可以找到最耗时的SQL,然后进行具体的SQL分析

慢查询相关的配置参数:
log_slow_queries:是否打开慢查询日志,得先确保=ON后面才有得分析

long_query_time:查询时间大于多少秒的SQL被当做是慢查询,一般设为1S

log_queries_not_using_indexes:是否将没有使用索引的记录写入慢查询日志

slow_query_log_file:慢查询日志存放路径

三、如何针对具体的SQL做优化?

使用Explain分析SQL语句执行计划
MySQL> explain select * from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > 123456789;
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
| 1 | SIMPLE | t_online_group_records | ALL | NULL | NULL | NULL | NULL | 47 | Using where |
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)如上面例子所示,重点关注下type,rows和Extra:

type:使用类别,有无使用到索引。结果值从好到坏:... > range(使用到索引) > index > ALL(全表扫描),一般查询应达到range级别

rows:SQL执行检查的记录数

Extra:SQL执行的附加信息,如"Using index"表示查询只用到索引列,不需要去读表等

使用Profiles分析SQL语句执行时间和消耗资源:
MySQL> set profiling=1; (启动profiles,默认是没开启的)
MySQL> select count(1) from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > 123456789; (执行要分析的SQL语句)
MySQL> show profiles;
+----------+------------+----------------------------------------------------------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+----------------------------------------------------------------------------------------------+
| 1 | 0.00043250 | select count(1) from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > 123456789 |
+----------+------------+----------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
MySQL> show profile cpu,block io for query 1; (可看出SQL在各个环节的耗时和资源消耗)
+----------------------+----------+----------+------------+--------------+---------------+
| Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |
+----------------------+----------+----------+------------+--------------+---------------+
...
| optimizing | 0.000016 | 0.000000 | 0.000000 | 0 | 0 |
| statistics | 0.000020 | 0.000000 | 0.000000 | 0 | 0 |
| preparing | 0.000017 | 0.000000 | 0.000000 | 0 | 0 |
| executing | 0.000011 | 0.000000 | 0.000000 | 0 | 0 |
| Sending data | 0.000076 | 0.000000 | 0.000000 | 0 | 0 |
...
SQL优化的技巧 (只提一些业务常遇到的问题)
 
1、最关键:索引,避免全表扫描
对接触的项目进行慢查询分析,发现TOP10的基本都是忘了加索引或者索引使用不当,如索引字段上加函数导致索引失效等(如where UNIX_TIMESTAMP(gre_updatetime)>123456789)
+----------+------------+---------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+---------------------------------------+
| 1 | 0.00024700 | select * from mytable where id=100 |
| 2 | 0.27912900 | select * from mytable where id+1=101 |
+----------+------------+---------------------------------------+另外很多同学在拉取全表数据时,喜欢用select xx from xx limit 5000,1000这种形式批量拉取,其实这个SQL每次都是全表扫描,建议添加1个自增id做索引,将SQL改为 select xx from xx where id>5000 and id<6000;
+----------+------------+-----------------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+-----------------------------------------------------+
| 1 | 0.00415400 | select * from mytable where id>=90000 and id<=91000 |
| 2 | 0.10078100 | select * from mytable limit 90000,1000 |
+----------+------------+-----------------------------------------------------+合理用好索引,应该可解决大部分SQL问题。当然索引也非越多越好,过多的索引会影响写操作性能。
 
1.1 只select出需要的字段,避免select
+----------+------------+-----------------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+-----------------------------------------------------+
| 1 | 0.02948800 | select count(1) from ( select id from mytable ) a |
| 2 | 1.34369100 | select count(1) from ( select * from mytable ) a |
+----------+------------+-----------------------------------------------------+1.2 尽量早做过滤,使Join或者Union等后续操作的数据量尽量小
 
1.3 把能在逻辑层算的提到逻辑层来处理,如一些数据排序、时间函数计算等
 
PS:关于SQL优化,已经有足够多文章了,所以就不讲太全面了,只重点说自己1个感受:索引!基本都是因为索引!
 

四、SQL层面已难以优化,请求量继续增大时的应对策略?

下面是我能想到的几个方法,每个方法又都是一篇大文章了,这里就不展开。
分库分表使用集群(master-slave),读写分离增加业务的cache层使用连接池

五、MySQL如何做主从数据同步?

复制机制(Replication)
master通过复制机制,将master的写操作通过binlog传到slave生成中继日志(relaylog),slave再将中继日志redo,使得主库和从库的数据保持同步。
 
复制相关的3个MySQL线程:
slave上的I/O线程:向master请求数据master上的Binlog Dump线程:读取binlog事件并把数据发送给slave的I/O线程slave上的SQL线程:读取中继日志并执行,更新数据库
属于slave主动请求拉取的模式
 
实际使用可能遇到的问题
数据非强一致:CDB默认为异步复制,master和slave的数据会有一定延迟(称为主从同步距离,一般 < 1s)
主从同步距离变大:可能是DB写入压力大,也可能是slave机器负载高,网络波动等原因,具体问题具体分析
 
相关监控命令
show processlist:查看MySQL进程信息,包括3个同步线程的当前状态

show master status :查看master配置及当前复制信息

show slave status:查看slave配置及当前复制信息

六、如何防止DB误操作和做好容灾?

业务侧应做到的几点:
重要DB数据的手工修改操作,操作前需做到2点:1 先在测试环境操作 2 备份数据根据业务重要性做定时备份,考虑系统可承受的恢复时间进行容灾演练,感觉很必要
 
MySQL备份和恢复操作
 
1、备份:使用MySQLdump导出数据
MySQLdump -u 用户名 -p 数据库名 [表名] > 导出的文件名
MySQLdump -uxxx -p xxx mytable > mytable.20140921.bak.sql2、恢复:导入备份数据
MySQL -uxxx -p xxxx < mytable.20140921.bak.sql3、恢复:导入备份数据之后发送的写操作。先使用MySQLbinlog导出这部分写操作SQL(基于时间点或位置)
如导出2014-09-21 09:59:59之后的binlog:
MySQLbinlog --database="test" --start-date="2014-09-21 09:59:59" /var/lib/MySQL/mybinlog.000001 > binlog.data.sql如导出起始id为123456之后的binlog:
MySQLbinlog --database="test" --start-position="123456" /var/lib/MySQL/mybinlog.000001 > binlog.data.sql最后把要恢复的binlog导入db
MySQL -uxxxx -p xxxx < binlog.data.sql

七、该选择MySQL哪种存储引擎,Innodb具有什么特性?

存储引擎简介:
插件式存储引擎是MySQL的重要特性,MySQL支持多种存储引擎以满足用户的多种应用场景
存储引擎解决的问题:如何组织MySQL数据在介质中高效地读取,需考虑存储机制、索引设计、并发读写的锁机制等
MySQL5.0支持的存储引擎有MyISAM、InnoDB、Memory、Merge等
 
MyISAM和InnoDB的区别(只说重点了)
 
1. InnoDB,MySQL5.5之后及CDB的默认引擎
支持行锁:并发性能好支持事务:故InnoDB称为事务性存储引擎,支持ACID,提供了具有提交、回滚和崩溃恢复能力的事务安全支持外键:当前唯一支持外键的引擎
 
2. MyISAM,MySQL5.5之前默认引擎
支持表锁:插入+查询速度快,更新+删除速度慢不支持事务
 
使用show engines可查看当前MySQL支持的存储引擎详情:




 

八、MySQL内部结构有哪些层次?

 
非专业DBA,这里只简单贴个结构图说明下。MySQL是开源系统,其设计思路和源代码都出自大牛之手,有空可以学习下。




Connectors:连接器。接收不同语言的Client交互Management Serveices & Utilities:系统管理和控制工具Connection Pool: 连接池。管理用户连接SQL Interface: SQL接口。接受用户的SQL命令,并且返回用户需要查询的结果Parser: 解析器。验证和解析SQL语句成内部数据结构Optimizer: 查询优化器。为查询语句选择合适的执行路径Cache和Buffer:查询缓存。缓存查询的结果,有命中即可直接返回Engine:存储引擎。MySQL数据最后组织并存储成具体文件
 
作者:王昂 
原文地址:https://www.qcloud.com/community/article/233  查看全部
最近研发的项目对 DB 依赖比较重,梳理了这段时间使用MySQL遇到的8个比较具有代表性的问题,答案也比较偏自己的开发实践,没有 DBA专业和深入,有出入的请使劲拍砖!
 


一、MySQL读写性能是多少,有哪些性能相关的重要参数?​


这里做了几个简单压测实验,结果如下:
机器:8核CPU,8G内存
表结构(尽量模拟业务):12个字段(1个bigint(20)为自增primary key,5个int(11),5个varchar(512),1个timestamp),InnoDB存储引擎。
实验1(写):insert => 6000/s
前提:连接数100,每次insert单条记录
分析:CPU跑了50%,这时磁盘为顺序写,故性能较高
实验2(写):update(where条件命中索引) => 200/s
前提:连接数100,10w条记录,每次update单条记录的4个字段(2个int(11),2个varchar(512))
分析:CPU跑2%,瓶颈明显在IO的随机写
实验3(读):select(where条件命中索引) => 5000/s
前提:连接数100,10w条记录,每次select单条记录的4个字段(2个int(11),2个varchar(512))
分析:CPU跑6%,瓶颈在IO,和db的cache大小相关
实验4(读):select(where条件没命中索引) => 60/s
前提:连接数100,10w条记录,每次select单条记录的4个字段(2个int(11),2个varchar(512))
分析:CPU跑到80%,每次select都需遍历所有记录,看来索引的效果非常明显!
几个重要的配置参数,可根据实际的机器和业务特点调整
max_connecttions:最大连接数

table_cache:缓存打开表的数量

key_buffer_size:索引缓存大小

query_cache_size:查询缓存大小

sort_buffer_size:排序缓存大小(会将排序完的数据缓存起来)

read_buffer_size:顺序读缓存大小

read_rnd_buffer_size:某种特定顺序读缓存大小(如order by子句的查询)
PS:查看配置方法:show variables like '%max_connecttions%';
 


二、MySQL负载高时,如何找到是由哪些SQL引起的?


方法:慢查询日志分析(MySQLdumpslow)
 
慢查询日志例子,可看到每个慢查询SQL的耗时:
# User@Host: edu_online[edu_online] @  [10.139.10.167]
# Query_time: 1.958000 Lock_time: 0.000021 Rows_sent: 254786 Rows_examined: 254786
SET timestamp=1410883292;
select * from t_online_group_records;
日志显示该查询用了1.958秒,返回254786行记录,一共遍历了254786行记录。及具体的时间戳和SQL语句。

使用MySQLdumpslow进行慢查询日志分析:

MySQLdumpslow -s t -t 5 slow_log_20140819.txt
输出查询耗时最多的Top5条SQL语句
 
-s:排序方法,t表示按时间 (此外,c为按次数,r为按返回记录数等)
-t:去Top多少条,-t 5表示取前5条
 
执行完分析结果如下:
Count: 1076100  Time=0.09s (99065s)  Lock=0.00s (76s)  Rows=408.9 (440058825), edu_online[edu_online]@28hosts
select * from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > N
Count: 1076099 Time=0.05s (52340s) Lock=0.00s (91s) Rows=62.6 (67324907), edu_online[edu_online]@28hosts
select * from t_online_course where UNIX_TIMESTAMP(c_updatetime) > N
Count: 63889 Time=0.78s (49607s) Lock=0.00s (3s) Rows=0.0 (18), edu_online[edu_online]@[10x.213.1xx.1xx]
select f_uin from t_online_student_contact where f_modify_time > N
Count: 1076097 Time=0.02s (16903s) Lock=0.00s (72s) Rows=52.2 (56187090), edu_online[edu_online]@28hosts
select * from t_online_video_info where UNIX_TIMESTAMP(v_update_time) > N
Count: 330046 Time=0.02s (6822s) Lock=0.00s (45s) Rows=0.0 (2302), edu_online[edu_online]@4hosts
select uin,cid,is_canceled,unix_timestamp(end_time) as endtime,unix_timestamp(update_time) as updatetime
from t_kick_log where unix_timestamp(update_time) > N
以第1条为例,表示这类SQL(N可以取很多值,这里MySQLdumpslow会归并起来)在8月19号的慢查询日志内出现了1076100次,总耗时99065秒,总返回440058825行记录,有28个客户端IP用到。

通过慢查询日志分析,就可以找到最耗时的SQL,然后进行具体的SQL分析

慢查询相关的配置参数:
log_slow_queries:是否打开慢查询日志,得先确保=ON后面才有得分析

long_query_time:查询时间大于多少秒的SQL被当做是慢查询,一般设为1S

log_queries_not_using_indexes:是否将没有使用索引的记录写入慢查询日志

slow_query_log_file:慢查询日志存放路径


三、如何针对具体的SQL做优化?


使用Explain分析SQL语句执行计划
MySQL> explain select * from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > 123456789;
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
| 1 | SIMPLE | t_online_group_records | ALL | NULL | NULL | NULL | NULL | 47 | Using where |
+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)
如上面例子所示,重点关注下type,rows和Extra:

type:使用类别,有无使用到索引。结果值从好到坏:... > range(使用到索引) > index > ALL(全表扫描),一般查询应达到range级别

rows:SQL执行检查的记录数

Extra:SQL执行的附加信息,如"Using index"表示查询只用到索引列,不需要去读表等

使用Profiles分析SQL语句执行时间和消耗资源:
MySQL> set profiling=1; (启动profiles,默认是没开启的)
MySQL> select count(1) from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > 123456789; (执行要分析的SQL语句)
MySQL> show profiles;
+----------+------------+----------------------------------------------------------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+----------------------------------------------------------------------------------------------+
| 1 | 0.00043250 | select count(1) from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > 123456789 |
+----------+------------+----------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
MySQL> show profile cpu,block io for query 1; (可看出SQL在各个环节的耗时和资源消耗)
+----------------------+----------+----------+------------+--------------+---------------+
| Status | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |
+----------------------+----------+----------+------------+--------------+---------------+
...
| optimizing | 0.000016 | 0.000000 | 0.000000 | 0 | 0 |
| statistics | 0.000020 | 0.000000 | 0.000000 | 0 | 0 |
| preparing | 0.000017 | 0.000000 | 0.000000 | 0 | 0 |
| executing | 0.000011 | 0.000000 | 0.000000 | 0 | 0 |
| Sending data | 0.000076 | 0.000000 | 0.000000 | 0 | 0 |
...

SQL优化的技巧 (只提一些业务常遇到的问题)
 
1、最关键:索引,避免全表扫描
对接触的项目进行慢查询分析,发现TOP10的基本都是忘了加索引或者索引使用不当,如索引字段上加函数导致索引失效等(如where UNIX_TIMESTAMP(gre_updatetime)>123456789)
+----------+------------+---------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+---------------------------------------+
| 1 | 0.00024700 | select * from mytable where id=100 |
| 2 | 0.27912900 | select * from mytable where id+1=101 |
+----------+------------+---------------------------------------+
另外很多同学在拉取全表数据时,喜欢用select xx from xx limit 5000,1000这种形式批量拉取,其实这个SQL每次都是全表扫描,建议添加1个自增id做索引,将SQL改为 select xx from xx where id>5000 and id<6000;
+----------+------------+-----------------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+-----------------------------------------------------+
| 1 | 0.00415400 | select * from mytable where id>=90000 and id<=91000 |
| 2 | 0.10078100 | select * from mytable limit 90000,1000 |
+----------+------------+-----------------------------------------------------+
合理用好索引,应该可解决大部分SQL问题。当然索引也非越多越好,过多的索引会影响写操作性能。
 
1.1 只select出需要的字段,避免select
+----------+------------+-----------------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+-----------------------------------------------------+
| 1 | 0.02948800 | select count(1) from ( select id from mytable ) a |
| 2 | 1.34369100 | select count(1) from ( select * from mytable ) a |
+----------+------------+-----------------------------------------------------+
1.2 尽量早做过滤,使Join或者Union等后续操作的数据量尽量小
 
1.3 把能在逻辑层算的提到逻辑层来处理,如一些数据排序、时间函数计算等
 
PS:关于SQL优化,已经有足够多文章了,所以就不讲太全面了,只重点说自己1个感受:索引!基本都是因为索引!
 


四、SQL层面已难以优化,请求量继续增大时的应对策略?


下面是我能想到的几个方法,每个方法又都是一篇大文章了,这里就不展开。
  • 分库分表
  • 使用集群(master-slave),读写分离
  • 增加业务的cache层
  • 使用连接池


五、MySQL如何做主从数据同步?


复制机制(Replication)
master通过复制机制,将master的写操作通过binlog传到slave生成中继日志(relaylog),slave再将中继日志redo,使得主库和从库的数据保持同步。
 
复制相关的3个MySQL线程
  1. slave上的I/O线程:向master请求数据
  2. master上的Binlog Dump线程:读取binlog事件并把数据发送给slave的I/O线程
  3. slave上的SQL线程:读取中继日志并执行,更新数据库

属于slave主动请求拉取的模式
 
实际使用可能遇到的问题
数据非强一致:CDB默认为异步复制,master和slave的数据会有一定延迟(称为主从同步距离,一般 < 1s)
主从同步距离变大:可能是DB写入压力大,也可能是slave机器负载高,网络波动等原因,具体问题具体分析
 
相关监控命令
show processlist:查看MySQL进程信息,包括3个同步线程的当前状态

show master status :查看master配置及当前复制信息

show slave status:查看slave配置及当前复制信息


六、如何防止DB误操作和做好容灾?


业务侧应做到的几点:
  • 重要DB数据的手工修改操作,操作前需做到2点:1 先在测试环境操作 2 备份数据
  • 根据业务重要性做定时备份,考虑系统可承受的恢复时间
  • 进行容灾演练,感觉很必要

 
MySQL备份和恢复操作
 
1、备份:使用MySQLdump导出数据
MySQLdump -u 用户名 -p 数据库名 [表名] > 导出的文件名
MySQLdump -uxxx -p xxx mytable > mytable.20140921.bak.sql
2、恢复:导入备份数据
MySQL -uxxx -p xxxx < mytable.20140921.bak.sql
3、恢复:导入备份数据之后发送的写操作。先使用MySQLbinlog导出这部分写操作SQL(基于时间点或位置)
如导出2014-09-21 09:59:59之后的binlog:
MySQLbinlog --database="test" --start-date="2014-09-21 09:59:59" /var/lib/MySQL/mybinlog.000001 > binlog.data.sql
如导出起始id为123456之后的binlog:
MySQLbinlog --database="test" --start-position="123456" /var/lib/MySQL/mybinlog.000001 > binlog.data.sql
最后把要恢复的binlog导入db
MySQL -uxxxx -p xxxx < binlog.data.sql


七、该选择MySQL哪种存储引擎,Innodb具有什么特性?


存储引擎简介:
插件式存储引擎是MySQL的重要特性,MySQL支持多种存储引擎以满足用户的多种应用场景
存储引擎解决的问题:如何组织MySQL数据在介质中高效地读取,需考虑存储机制、索引设计、并发读写的锁机制等
MySQL5.0支持的存储引擎有MyISAM、InnoDB、Memory、Merge等
 
MyISAM和InnoDB的区别(只说重点了)
 
1. InnoDB,MySQL5.5之后及CDB的默认引擎
  • 支持行锁:并发性能好
  • 支持事务:故InnoDB称为事务性存储引擎,支持ACID,提供了具有提交、回滚和崩溃恢复能力的事务安全
  • 支持外键:当前唯一支持外键的引擎

 
2. MyISAM,MySQL5.5之前默认引擎
  • 支持表锁:插入+查询速度快,更新+删除速度慢
  • 不支持事务

 
使用show engines可查看当前MySQL支持的存储引擎详情:
engine.png

 


八、MySQL内部结构有哪些层次?


 
非专业DBA,这里只简单贴个结构图说明下。MySQL是开源系统,其设计思路和源代码都出自大牛之手,有空可以学习下。
connect.png

  1. Connectors:连接器。接收不同语言的Client交互
  2. Management Serveices & Utilities:系统管理和控制工具
  3. Connection Pool: 连接池。管理用户连接
  4. SQL Interface: SQL接口。接受用户的SQL命令,并且返回用户需要查询的结果
  5. Parser: 解析器。验证和解析SQL语句成内部数据结构
  6. Optimizer: 查询优化器。为查询语句选择合适的执行路径
  7. Cache和Buffer:查询缓存。缓存查询的结果,有命中即可直接返回
  8. Engine:存储引擎。MySQL数据最后组织并存储成具体文件

 
作者:王昂 
原文地址:https://www.qcloud.com/community/article/233 

云迁移过程中如何保证数据安全性

大数据/云计算OT学习平台 发表了文章 • 0 个评论 • 112 次浏览 • 2017-08-02 16:48 • 来自相关话题

由于成本的降低和业务的便捷性,越来越多的企业将自己的IT系统迁移到云端,而在迁移的过程中,从基础设施的部署到云平台的挑战都十分的具有挑战性,在迁移过程中,企业IT管理着最需要重视的一个问题就是:如何保证云迁移的安全,减少迁移风险。
为了降低向云端迁移的风险,保证数据的安全性,OTPUB认为企业可以通过下面三种方法着手策划数据向云的迁移。 
第一种方法是指将本地硬件或虚拟机上的数据迁移到与之相匹配的云上。该解决方案缺乏弹性,该方案通常是为了满足峰值负载而过度供应,这就会导致了云计算成本的增加,因此这种方法作为一种短期解决措施会更佳。
第二种方法是指对企业的应用技术进行重新架构。数据迁移需要花费一定时间,而且具有较强的强制性,而对企业技术进行重新架构反而会获得更好的性能。的确,重新对应用技术的选择进行评估也不失为一种更好的选择。因为企业可能会将一些解决方案从使用昂贵的商业软件转向开源产品上来。
第三种方法是搁置单一的本地应用程序,将程序内部数据迁移到SaaS。这种方法既实现了业务的现代化标准,又将基础架构和服务的运营负担转嫁给了SaaS提供商。
以上三种方法可以让企业在最佳情况下完成数据由本地向云端的迁移,同时最大限度的保证了迁移过程中数据的安全性。 查看全部
由于成本的降低和业务的便捷性,越来越多的企业将自己的IT系统迁移到云端,而在迁移的过程中,从基础设施的部署到云平台的挑战都十分的具有挑战性,在迁移过程中,企业IT管理着最需要重视的一个问题就是:如何保证云迁移的安全,减少迁移风险。
为了降低向云端迁移的风险,保证数据的安全性,OTPUB认为企业可以通过下面三种方法着手策划数据向云的迁移。 
第一种方法是指将本地硬件或虚拟机上的数据迁移到与之相匹配的云上。该解决方案缺乏弹性,该方案通常是为了满足峰值负载而过度供应,这就会导致了云计算成本的增加,因此这种方法作为一种短期解决措施会更佳。
第二种方法是指对企业的应用技术进行重新架构。数据迁移需要花费一定时间,而且具有较强的强制性,而对企业技术进行重新架构反而会获得更好的性能。的确,重新对应用技术的选择进行评估也不失为一种更好的选择。因为企业可能会将一些解决方案从使用昂贵的商业软件转向开源产品上来。
第三种方法是搁置单一的本地应用程序,将程序内部数据迁移到SaaS。这种方法既实现了业务的现代化标准,又将基础架构和服务的运营负担转嫁给了SaaS提供商。
以上三种方法可以让企业在最佳情况下完成数据由本地向云端的迁移,同时最大限度的保证了迁移过程中数据的安全性。

清除wnTKYg挖矿木马过程详解

运维技术chris 发表了文章 • 0 个评论 • 324 次浏览 • 2017-07-27 23:02 • 来自相关话题

 杀wnTKYg病毒分两步,第一是找到它的来源,切断入口,第二步,找到它的守护进程并杀死,然后再去杀死病毒进程,有的守护进程很隐蔽,唤醒病毒之后,自动消亡,这时候top就看不到了,要留心。
由于工作需要,我由一个专业java开发工程师,渐渐的也成为了不专业的资深的运维工程师了。最近项目在做性能测试,发现CPU使用率异常,无人访问时CPU也一直保持75%,然后在xShell上top了一下,发现wnTKYg这个程序CPU占用率300%.




很明显是病毒进程,下意识的把它kill了,但是一分钟之后又自动重启了,于是百度了一下,发现这个东西叫做挖矿工,简单的说,就是别人用你的服务器去做它自己的事,然后赚钱。       
 
知道wnTKYg是什么鬼之后,我不急着杀死它,先百度了一下它怎么进来的,百度上关于它的帖子特别少,说是钻了redis的空子进来的,我基本上赞同这个说法,第一步就是对redis进行了配置上的修改:
把默认的端口号6379给改了把密码改的更复杂了把bind xx.xx.x.x xx.xx.xx.xx改了
修改redis是防止这熊孩子再进来,第二步就是把已经入驻的木马杀死,它不仅使用我的服务器,它还登录我的账号,所以查看了 /root/.ssh 下的文件,在/root/.ssh/known_hosts中发现了我不认识的IP,绝对有问题,于是干脆把 /root/.ssh 下的文件都删了,省事了。
 
第三步就是要找到所有关于病毒的文件, 执行命令  find / -name wnTKYg*,只有/tmp下有这个文件,删了,然后就去kill wnTKYg进程,你以为这样它就可以死了吗?Never!一分钟之后它又复活了,我猜测一定有守护进程在唤醒它,于是我再kill  然后top观察进行变化,终于被我发现了,有一个/tmp/ddg.1007进程很可疑,于是百度这个东东验证了一下,果然,就是挖矿工的守护进程,用ps -aux|grep ddg 命令把所有ddg进程找出来杀掉,并删除/tmp目录下的所有的对应ddg文件,至此,病毒被解决了,异地登录,安全扫描什么的也被我解决了。
 
很多哥们也遇到了这个问题,加了我好友,并且描述了他们的一些情况,我会把他们的改进和补充也写在此贴里,有的哥们会有个定时任务下载这些东西,目录 /var/spool/cron,记得留意这个文件夹,如果遇到,就把它干掉。
 
安全问题依然严峻,于是找了一家安全公司--安全狗咨询了下相关的安全业务,发现蛮贵的,都是万开头的,而且我也不知道他们水平怎么样,于是把我遇到的问题跟业务员说了,看看他们怎么解决,怎么收费,谈判了一下午,定价3500,没的再低了,哎,还是我好,又为公司省了3500。
 
因为发了这篇帖子,一位和我情况差不多的网友也提供了一种解决方案,我把他的也贴进来与大家分享谢谢这位网友:首先关闭挖矿的服务器访问 :iptables -A INPUT -s xmr.crypto-pool.fr -j DROP
iptables -A OUTPUT -d xmr.crypto-pool.fr -j DROP然后删除yam 文件   用find / -name yam查找yam 文件    之后 找到wnTKYg 所在目录 取消掉其权限  并删除 然后再取消掉 tmp 的权限并删除  之后 pkill  wnTKYg就OK了。
 
当然,我也咨询了阿里的解决方案,有两个,①找第三方安全公司杀②把数据备份一下,重置系统 。  坑爹的阿里啊。
 
分享阅读:点击原文。 查看全部
 杀wnTKYg病毒分两步,第一是找到它的来源,切断入口,第二步,找到它的守护进程并杀死,然后再去杀死病毒进程,有的守护进程很隐蔽,唤醒病毒之后,自动消亡,这时候top就看不到了,要留心。
由于工作需要,我由一个专业java开发工程师,渐渐的也成为了不专业的资深的运维工程师了。最近项目在做性能测试,发现CPU使用率异常,无人访问时CPU也一直保持75%,然后在xShell上top了一下,发现wnTKYg这个程序CPU占用率300%.
wntky.png

很明显是病毒进程,下意识的把它kill了,但是一分钟之后又自动重启了,于是百度了一下,发现这个东西叫做挖矿工,简单的说,就是别人用你的服务器去做它自己的事,然后赚钱。       
 
知道wnTKYg是什么鬼之后,我不急着杀死它,先百度了一下它怎么进来的,百度上关于它的帖子特别少,说是钻了redis的空子进来的,我基本上赞同这个说法,第一步就是对redis进行了配置上的修改:
  1. 把默认的端口号6379给改了
  2. 把密码改的更复杂了
  3. 把bind xx.xx.x.x xx.xx.xx.xx改了

修改redis是防止这熊孩子再进来,第二步就是把已经入驻的木马杀死,它不仅使用我的服务器,它还登录我的账号,所以查看了 /root/.ssh 下的文件,在/root/.ssh/known_hosts中发现了我不认识的IP,绝对有问题,于是干脆把 /root/.ssh 下的文件都删了,省事了。
 
第三步就是要找到所有关于病毒的文件, 执行命令  find / -name wnTKYg*,只有/tmp下有这个文件,删了,然后就去kill wnTKYg进程,你以为这样它就可以死了吗?Never!一分钟之后它又复活了,我猜测一定有守护进程在唤醒它,于是我再kill  然后top观察进行变化,终于被我发现了,有一个/tmp/ddg.1007进程很可疑,于是百度这个东东验证了一下,果然,就是挖矿工的守护进程,用ps -aux|grep ddg 命令把所有ddg进程找出来杀掉,并删除/tmp目录下的所有的对应ddg文件,至此,病毒被解决了,异地登录,安全扫描什么的也被我解决了。
 
很多哥们也遇到了这个问题,加了我好友,并且描述了他们的一些情况,我会把他们的改进和补充也写在此贴里,有的哥们会有个定时任务下载这些东西,目录 /var/spool/cron,记得留意这个文件夹,如果遇到,就把它干掉
 
安全问题依然严峻,于是找了一家安全公司--安全狗咨询了下相关的安全业务,发现蛮贵的,都是万开头的,而且我也不知道他们水平怎么样,于是把我遇到的问题跟业务员说了,看看他们怎么解决,怎么收费,谈判了一下午,定价3500,没的再低了,哎,还是我好,又为公司省了3500
 
因为发了这篇帖子,一位和我情况差不多的网友也提供了一种解决方案,我把他的也贴进来与大家分享谢谢这位网友:首先关闭挖矿的服务器访问 :
iptables -A INPUT -s  xmr.crypto-pool.fr -j DROP
iptables -A OUTPUT -d xmr.crypto-pool.fr -j DROP
然后删除yam 文件   用find / -name yam查找yam 文件    之后 找到wnTKYg 所在目录 取消掉其权限  并删除 然后再取消掉 tmp 的权限并删除  之后 pkill  wnTKYg就OK了。
 
当然,我也咨询了阿里的解决方案,有两个,①找第三方安全公司杀②把数据备份一下,重置系统 。  坑爹的阿里啊。
 
分享阅读:点击原文

InnoDB: Error: Table "mysql"."innodb_table_stats" not found.

数据库采菊篱下 回复了问题 • 2 人关注 • 1 个回复 • 222 次浏览 • 2017-07-18 22:02 • 来自相关话题

MySQL之BLGC介绍

数据库Rock 发表了文章 • 0 个评论 • 155 次浏览 • 2017-07-08 23:51 • 来自相关话题

一、组提交介绍

1.1 什么是组提交
Binary Log Group Commit 即二进制日志组提交。这是 MySQL5.6 版本中引进的一个新的特性。为什么需要引进这个特性呢?我们知道当我们把 MySQL 的 binlog 开启的时候,MySQL 会将每个事务的操作都记录到 binlog 中,方便我们使用 binlog 来完成复制或者恢复操作。可是需要调用 fsync() 才能将缓存中被更改的 binlog 真正的写到磁盘上,保证数据的持久化。但是这是一个从内存写到磁盘的过程,I/O 比较慢。如果每次事务提交都执行一遍 fsync() 将 binlog 持久化落盘到磁盘的话,效率很低。于是就想,能不能等几个事务的 binlog 一起调用一次 fsync(),一次性落盘。减少 fsync() 的次数,从而提高效率。这就是二进制日志组提交的概念。
 

二、两阶段提交

2.1 为什么需要二阶段提交
我们知道在 MySQL 中不仅仅有 binlog,还有 redo log 和 undo log 。binlog 用来记录每个事务的操作信息,redo 是在数据库宕机恢复时使用,用来恢复数据库数据,undo 用来回滚还未被提交的数据。binlog 是在数据库 Server 层产生的,即它会记录所有存储引擎中事务的操作,而 redo 是 InnoDB 存储引擎特有的日志。

在事务提交的时候,我们需要先写入二进制日志,再写 InnoDB 存储引擎的 redo。并且要求二进制日志和 redo 要么都写,要么都不写。不然可能会出现这样的情况:在主从复制的环境下,master 提交了一个事务,先写了二进制日志,但是在要写 InnoDB 存储引擎的时候,数据库发生了宕机,此时 binlog 又已经被 slave 接收到了,slave 会执行这个事务,但是实际 master 上并没有这个事务。这就会导致主从数据的不一致。所以我们引入了二阶段提交来解决这个问题,即将写 binlog 操作个 InnoDB 提交操作通过事务变成原子的。
 
2.2 什么是二阶段提交
所谓的二阶段提交就是,我在事务提交的时候,确保先将 binlog 写入,然后再到数据引擎层提交,并且这两个操作是原子的。在 MySQL 中用内部的 XA 事务来完成,即将这两个操作包装成一个事务的概念。




上图表示了二阶段提交的过程。当一个会话中的某一事务 COMMIT 的时候,进去二阶段提交的过程。首先数据库先去协调 Server 层和 Engine,询问是否都可以开始写日志,这个过程就是图中的的 prepare 阶段。协调好两层之间的关系,Server 层和 Engine 层都表示可以写日志,这时候进入下一个过程。

第二个过程就是写 binlog 的过程,先把 binlog 写到内存中,然后调用 fsync() 将 binlog 从内存写到磁盘上。

第三个过程就是在存储引擎层提交的过程,将真实修改的数据提交到数据库中。当这一步完成才最终返回给会话一个 COMMIT 成功的信号。

这整个过程就是二阶段提交的过程,如果在 fsync() 之前数据库 crash 了,重启之后数据将会被回滚,若在 fsync() 之后 crash,则会进行重做操作。通过二阶段提交的方式就保证了存储引擎与二进制日志保持一致。
 

三、三阶段提交

3.1 为什么需要三阶段提交
上面的二阶段提交是针对单一事务提交时候的操作顺序,下面我们来看看当多个事务并发的时候会是什么样的一个情况。




现在有T1、T2、T3 三个事务需要执行,从图中可以看到数据在 fsync() 之前,三个事务已经写入到了 binlog 中,通过 fsync() 操作将 binlog 刷到磁盘。之后先是 T2 COMMIT,将数据更改更新到存储引擎层,接着是 T3 COMMIT,将数据更新到存储引擎层。这时候我们做了一个热备份的操作,有多种方式进行数据库的热备份,比如:XtraBackup等。这时候就会发生错误。会发生什么错误,我们需要先了解一下 XtraBackup 等热备工具的备份原理。

XtraBackup备份原理:直接拷贝数据库文件,并且记录下当前二进制日志中已经提交的最后一个事务标记。在新的数据库实例上完成 recovery 操作。

了解完备份原理之后,我们就可以想到上述情况下做热备会出现什么情况。因为 T2、T3 已经提交,所以备份的时候会记录下 T3 是最后一个提交的事务,会认为 T3 之前的事务都是已经提交的,由于是直接拷贝数据库文件,可以看到 T1 事务的数据还没有提交到存储引擎层,所以备份数据中还并没有 T1 的数据。如果新的数据库是用来做主从复制的话,change master to 会指向二进制日志中 T3 的位置,从 T3 事务开始往后进行复制,这样一来 T1 事务的数据就这样没了。产生这个问题的主要原因就是:事务写入二进制日志的顺序与事务在存储引擎层提交的顺序不一致。

为了解决这个问题,MySQL 引入了 prepare_commit_mutext 的机制,当事务提交的时候,需要先获得 prepare_commit_mutext 这个锁。有了这个锁就可以保证事务写入二进制日志的顺序与事务在存储引擎层提交的顺序一致。




但是这样一来,从图中我们也可以看到,原先是并发的事务,又变成了串行的,效率又变低了。只要是问题,必然存在解决方法。于是三阶段提交就出现了。
 
 
3.2 什么是三阶段提交
三阶段提交,顾名思义有三个阶段: Flush 阶段、sync 阶段、commit 阶段。分别对应的就是二进制日志写内存的阶段、二进制日志刷盘的阶段、事务提交到存储引擎层的阶段。
 




每个阶段都有 leader、follower 两种角色。当一个事务进入三个阶段中的某一个阶段,如果发现这个阶段中的队列为空,那么这个事务就会成为 leader 的角色,之后进入同一阶段的事务,发现这个阶段的队列中已经有事务存在了,那就变成 follower 角色。leader 角色的任务是安排当前阶段队列中的事务按顺序执行,并且带领队列中所有的事务进入下一个阶段。当 leader 带领队列中的事务进入下一阶段的时候,如果发现下一阶段中已经有事务存在(即下一阶段已有 leader 存在),新来的 leader 自动变成 follower 角色。

三阶段提交在每个阶段都控制了事务的顺序,从而也就控制了事务执行的整体顺序。解决了 prepare_commit_mutex 锁导致的问题,事务可以并发的执行。

参考:http://blog.itpub.net/28218939/viewspace-1975809/
           http://blog.itpub.net/28218939/viewspace-1975822/
http://mysqlmusings.blogspot.jp/2012/06/binary-log-group-commit-in-mysql-56.html   查看全部


一、组提交介绍


1.1 什么是组提交
Binary Log Group Commit 即二进制日志组提交。这是 MySQL5.6 版本中引进的一个新的特性。为什么需要引进这个特性呢?我们知道当我们把 MySQL 的 binlog 开启的时候,MySQL 会将每个事务的操作都记录到 binlog 中,方便我们使用 binlog 来完成复制或者恢复操作。可是需要调用 fsync() 才能将缓存中被更改的 binlog 真正的写到磁盘上,保证数据的持久化。但是这是一个从内存写到磁盘的过程,I/O 比较慢。如果每次事务提交都执行一遍 fsync() 将 binlog 持久化落盘到磁盘的话,效率很低。于是就想,能不能等几个事务的 binlog 一起调用一次 fsync(),一次性落盘。减少 fsync() 的次数,从而提高效率。这就是二进制日志组提交的概念。
 


二、两阶段提交


2.1 为什么需要二阶段提交
我们知道在 MySQL 中不仅仅有 binlog,还有 redo log 和 undo log 。binlog 用来记录每个事务的操作信息,redo 是在数据库宕机恢复时使用,用来恢复数据库数据,undo 用来回滚还未被提交的数据。binlog 是在数据库 Server 层产生的,即它会记录所有存储引擎中事务的操作,而 redo 是 InnoDB 存储引擎特有的日志。

在事务提交的时候,我们需要先写入二进制日志,再写 InnoDB 存储引擎的 redo。并且要求二进制日志和 redo 要么都写,要么都不写。不然可能会出现这样的情况:在主从复制的环境下,master 提交了一个事务,先写了二进制日志,但是在要写 InnoDB 存储引擎的时候,数据库发生了宕机,此时 binlog 又已经被 slave 接收到了,slave 会执行这个事务,但是实际 master 上并没有这个事务。这就会导致主从数据的不一致。所以我们引入了二阶段提交来解决这个问题,即将写 binlog 操作个 InnoDB 提交操作通过事务变成原子的。
 
2.2 什么是二阶段提交
所谓的二阶段提交就是,我在事务提交的时候,确保先将 binlog 写入,然后再到数据引擎层提交,并且这两个操作是原子的。在 MySQL 中用内部的 XA 事务来完成,即将这两个操作包装成一个事务的概念。
twocommit.png

上图表示了二阶段提交的过程。当一个会话中的某一事务 COMMIT 的时候,进去二阶段提交的过程。首先数据库先去协调 Server 层和 Engine,询问是否都可以开始写日志,这个过程就是图中的的 prepare 阶段。协调好两层之间的关系,Server 层和 Engine 层都表示可以写日志,这时候进入下一个过程。

第二个过程就是写 binlog 的过程,先把 binlog 写到内存中,然后调用 fsync() 将 binlog 从内存写到磁盘上。

第三个过程就是在存储引擎层提交的过程,将真实修改的数据提交到数据库中。当这一步完成才最终返回给会话一个 COMMIT 成功的信号。

这整个过程就是二阶段提交的过程,如果在 fsync() 之前数据库 crash 了,重启之后数据将会被回滚,若在 fsync() 之后 crash,则会进行重做操作。通过二阶段提交的方式就保证了存储引擎与二进制日志保持一致
 


三、三阶段提交


3.1 为什么需要三阶段提交
上面的二阶段提交是针对单一事务提交时候的操作顺序,下面我们来看看当多个事务并发的时候会是什么样的一个情况。
t3commit.png

现在有T1、T2、T3 三个事务需要执行,从图中可以看到数据在 fsync() 之前,三个事务已经写入到了 binlog 中,通过 fsync() 操作将 binlog 刷到磁盘。之后先是 T2 COMMIT,将数据更改更新到存储引擎层,接着是 T3 COMMIT,将数据更新到存储引擎层。这时候我们做了一个热备份的操作,有多种方式进行数据库的热备份,比如:XtraBackup等。这时候就会发生错误。会发生什么错误,我们需要先了解一下 XtraBackup 等热备工具的备份原理。

XtraBackup备份原理:直接拷贝数据库文件,并且记录下当前二进制日志中已经提交的最后一个事务标记。在新的数据库实例上完成 recovery 操作。

了解完备份原理之后,我们就可以想到上述情况下做热备会出现什么情况。因为 T2、T3 已经提交,所以备份的时候会记录下 T3 是最后一个提交的事务,会认为 T3 之前的事务都是已经提交的,由于是直接拷贝数据库文件,可以看到 T1 事务的数据还没有提交到存储引擎层,所以备份数据中还并没有 T1 的数据。如果新的数据库是用来做主从复制的话,change master to 会指向二进制日志中 T3 的位置,从 T3 事务开始往后进行复制,这样一来 T1 事务的数据就这样没了。产生这个问题的主要原因就是:事务写入二进制日志的顺序与事务在存储引擎层提交的顺序不一致。

为了解决这个问题,MySQL 引入了 prepare_commit_mutext 的机制,当事务提交的时候,需要先获得 prepare_commit_mutext 这个锁。有了这个锁就可以保证事务写入二进制日志的顺序与事务在存储引擎层提交的顺序一致。
3tcommit.png

但是这样一来,从图中我们也可以看到,原先是并发的事务,又变成了串行的,效率又变低了。只要是问题,必然存在解决方法。于是三阶段提交就出现了。
 
 
3.2 什么是三阶段提交
三阶段提交,顾名思义有三个阶段: Flush 阶段、sync 阶段、commit 阶段。分别对应的就是二进制日志写内存的阶段、二进制日志刷盘的阶段、事务提交到存储引擎层的阶段。
 
3commit.png

每个阶段都有 leader、follower 两种角色。当一个事务进入三个阶段中的某一个阶段,如果发现这个阶段中的队列为空,那么这个事务就会成为 leader 的角色,之后进入同一阶段的事务,发现这个阶段的队列中已经有事务存在了,那就变成 follower 角色。leader 角色的任务是安排当前阶段队列中的事务按顺序执行,并且带领队列中所有的事务进入下一个阶段。当 leader 带领队列中的事务进入下一阶段的时候,如果发现下一阶段中已经有事务存在(即下一阶段已有 leader 存在),新来的 leader 自动变成 follower 角色。

三阶段提交在每个阶段都控制了事务的顺序,从而也就控制了事务执行的整体顺序。解决了 prepare_commit_mutex 锁导致的问题,事务可以并发的执行。


参考:http://blog.itpub.net/28218939/viewspace-1975809/
           http://blog.itpub.net/28218939/viewspace-1975822/
http://mysqlmusings.blogspot.jp/2012/06/binary-log-group-commit-in-mysql-56.html  


单独编译添加PHP的pdo_mysql模块

运维技术being 发表了文章 • 0 个评论 • 270 次浏览 • 2017-06-14 22:53 • 来自相关话题

原来编译php的时候,没有把pdo_mysql相关的参数带上,安装完后才发现。再重新编译有点费时间,所以决定单独来安装。
 
先找需要的版本,我用的是稳定的版本。要先看看说明,特别是要注意mysql的php的版本
# wget http://pecl.php.net/get/PDO_MYSQL-1.0.2.tgz
# tar xzvf PDO_MYSQL-1.0.2.tgz
# cd PDO_MYSQL-1.0.2
# /usr/local/php/bin/phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519
# ./configure执行完以后,报如下错误:
checking for mysql_config... not found
configure: error: Cannot find MySQL header files under这个错误表明系统缺省没有找到你的mysql安装目录,因此可以使用这个命令解决:ln -s /usr/local/mysql/bin/mysql_config /usr/bin/mysql_config这样建立了你的实际msyql安装目录和mysql_config命令的管理

经过configure就可以make了

在执行:./configure 时,又出现了一个问题:
checking for PDO includes... checking for PDO includes...
configure: error: Cannot find php_pdo_driver.h.检查的时候,不能找到php_pdo_driver.h,经过检查,发现在读php-config的时候,在读以前的配置。

解决方法:
./configure –with-php-config=/usr/local/php/bin/php-config (根据实际的路径的来指定)在执行./configure --with-php-config=/usr/local/php/bin/php-config,又出现了一个问题:
error: mysql_query missing!?解决方法:
./configure --with-php-config=/opt/php5/bin/php-config --with-pdo-mysql=/usr/local/mysql(根据自己的实际路径,设定编译安装mysql的位置).
make && make install注意pdo_mysql的全路径,我的是:
/usr/local/php/lib/php/extensions/no-debug-non-zts-20060613/pdo_mysql.so

然后在/usr/local/lib/php.ini加上一句:
extension=/usr/local/php/lib/php/extensions/no-debug-non-zts-20060613/pdo_mysql.so重新启动apache即可看到已经加载pdo_mysql成功。 查看全部
原来编译php的时候,没有把pdo_mysql相关的参数带上,安装完后才发现。再重新编译有点费时间,所以决定单独来安装。
 
先找需要的版本,我用的是稳定的版本。要先看看说明,特别是要注意mysql的php的版本
# wget http://pecl.php.net/get/PDO_MYSQL-1.0.2.tgz   
# tar xzvf PDO_MYSQL-1.0.2.tgz
# cd PDO_MYSQL-1.0.2
# /usr/local/php/bin/phpize
Configuring for:
PHP Api Version: 20041225
Zend Module Api No: 20060613
Zend Extension Api No: 220060519
# ./configure
执行完以后,报如下错误:
checking for mysql_config... not found  
configure: error: Cannot find MySQL header files under
这个错误表明系统缺省没有找到你的mysql安装目录,因此可以使用这个命令解决:
ln -s /usr/local/mysql/bin/mysql_config /usr/bin/mysql_config
这样建立了你的实际msyql安装目录和mysql_config命令的管理

经过configure就可以make了

在执行:./configure 时,又出现了一个问题:
checking for PDO includes... checking for PDO includes...  
configure: error: Cannot find php_pdo_driver.h.
检查的时候,不能找到php_pdo_driver.h,经过检查,发现在读php-config的时候,在读以前的配置。

解决方法:
./configure –with-php-config=/usr/local/php/bin/php-config (根据实际的路径的来指定)
在执行./configure --with-php-config=/usr/local/php/bin/php-config,又出现了一个问题:
error: mysql_query missing!?
解决方法:
./configure --with-php-config=/opt/php5/bin/php-config --with-pdo-mysql=/usr/local/mysql
(根据自己的实际路径,设定编译安装mysql的位置).
make && make install
注意pdo_mysql的全路径,我的是:
/usr/local/php/lib/php/extensions/no-debug-non-zts-20060613/pdo_mysql.so

然后在/usr/local/lib/php.ini加上一句:
extension=/usr/local/php/lib/php/extensions/no-debug-non-zts-20060613/pdo_mysql.so
重新启动apache即可看到已经加载pdo_mysql成功。

MYSQL的不同SQL模式解析

数据库chris 发表了文章 • 0 个评论 • 280 次浏览 • 2017-05-15 23:05 • 来自相关话题

一、Mysql SQL Mode简介

通常来说MySQL服务器能够工作在不同的SQL模式下,并能针对不同的客户端以不同的方式应用这些模式。这样,应用程序就能对服务器操作进行量身定制以满足自己的需求。
 
这类模式定义了MySQL应支持的SQL语法,以及应该在数据上执行何种确认检查。这样,就能在众多不同的环境下、与其他数据库服务器一起更容易地使用MySQL。
 
可以使用" --sql-mode="modes" "选项,通过启动mysqld来设置默认的SQL模式。而从MySQL 4.1开始,也能在启动之后,使用SET [SESSION|GLOBAL] sql_mode='modes'语句,通过设置sql_mode变量更改其模式。
 
通常在linux下安装完mysql后,其默认的sql-mode值是空,在这种情形下mysql执行的是一种不严格的检查,例如日期字段可以插入'0000-00-00 00:00:00'这样的值,还有如果要插入的字段长度超过列定义的长度,那么mysql不会终止操作,而是会自动截断后面的字符继续插入操作,如下例:
mysql> create table t1 (c1 char(3));
mysql> insert into t1 values('abcd');
mysql> select * from t1;
+------+
| c1 |
+------+
| abc |
+------+
1 row in set (0.00 sec)我们发现插入的字符被自动截断了,但是如果我们本意希望如果长度超过限制就报错,那么我们可以设置sql_mode为STRICT_TRANS_TABLES,如下:
mysql> set session sql_mode='STRICT_TRANS_TABLES'这样我们再执行同样的操作,mysql就会告诉我们插入的值太长,操作被终止,如下:
mysql> insert into t1 values('abcd');
ERROR 1406 (22001): Data too long for column 'c1' at row 1
经常使用的sql_mode值:




说明:如果把sql_mode的值设置成后面的两个值(也就是我们说的严格模式),那么当在列中插入或更新不正确的值时,mysql将会给出错误,并且放弃insert/update操作。
 
在我们的一般应用中建议使用这两种模式,而不是使用默认的空或ANSI模式。但是需要注意的问题是,如果数据库运行在严格模式下,并且你的存储引擎不支持事务,那么有数据不一致的风险存在,比如一组sql中有两个dml语句,如果后面的一个出现了问题,但是前面的已经操作成功,那么mysql并不能回滚前面的操作。因此说设置sql_mode需要应用人员权衡各种得失,从而得到一个合适的选择。
 
Sql_mode的值还有很多,这里不再累述,可以参考相关的手册。
 
 

二、SQL Mode与可移植性

如果mysql与其它异构数据库之间有数据移植的需求的话,那么下面的sql_mode的组合设置可以达到相应的效果:




 

三、SQL Mode与数据效验

SQL Mode 还可以实现对数据效验和转移等功能如: 
效验日期数据合法性. 在INSERT或UPDATE过程中,如果被零除(或MOD(X,0)),则产生错误 将‘"'视为识别符引号(‘`'引号字符) 禁用反斜线字符(‘\')做为字符串内的退出字符。启用NO_BACKSLASH_ESCAPES模式,反斜线则成为普通字符。 将||视为字符串连接操作符(+)(同CONCAT()),而不视为OR。 查看全部


一、Mysql SQL Mode简介


通常来说MySQL服务器能够工作在不同的SQL模式下,并能针对不同的客户端以不同的方式应用这些模式。这样,应用程序就能对服务器操作进行量身定制以满足自己的需求。
 
这类模式定义了MySQL应支持的SQL语法,以及应该在数据上执行何种确认检查。这样,就能在众多不同的环境下、与其他数据库服务器一起更容易地使用MySQL。
 
可以使用" --sql-mode="modes" "选项,通过启动mysqld来设置默认的SQL模式。而从MySQL 4.1开始,也能在启动之后,使用SET [SESSION|GLOBAL] sql_mode='modes'语句,通过设置sql_mode变量更改其模式。
 
通常在linux下安装完mysql后,其默认的sql-mode值是空,在这种情形下mysql执行的是一种不严格的检查,例如日期字段可以插入'0000-00-00 00:00:00'这样的值,还有如果要插入的字段长度超过列定义的长度,那么mysql不会终止操作,而是会自动截断后面的字符继续插入操作,如下例:
mysql> create table t1 (c1 char(3));
mysql> insert into t1 values('abcd');
mysql> select * from t1;
+------+
| c1 |
+------+
| abc |
+------+
1 row in set (0.00 sec)
我们发现插入的字符被自动截断了,但是如果我们本意希望如果长度超过限制就报错,那么我们可以设置sql_mode为STRICT_TRANS_TABLES,如下:
mysql> set session sql_mode='STRICT_TRANS_TABLES'
这样我们再执行同样的操作,mysql就会告诉我们插入的值太长,操作被终止,如下:
mysql> insert into t1 values('abcd');
ERROR 1406 (22001): Data too long for column 'c1' at row 1

经常使用的sql_mode值:
sqlmode.png

说明:如果把sql_mode的值设置成后面的两个值(也就是我们说的严格模式),那么当在列中插入或更新不正确的值时,mysql将会给出错误,并且放弃insert/update操作。
 
在我们的一般应用中建议使用这两种模式,而不是使用默认的空或ANSI模式。但是需要注意的问题是,如果数据库运行在严格模式下,并且你的存储引擎不支持事务,那么有数据不一致的风险存在,比如一组sql中有两个dml语句,如果后面的一个出现了问题,但是前面的已经操作成功,那么mysql并不能回滚前面的操作。因此说设置sql_mode需要应用人员权衡各种得失,从而得到一个合适的选择。
 
Sql_mode的值还有很多,这里不再累述,可以参考相关的手册。
 
 


二、SQL Mode与可移植性


如果mysql与其它异构数据库之间有数据移植的需求的话,那么下面的sql_mode的组合设置可以达到相应的效果:
databaseclass.png

 


三、SQL Mode与数据效验


SQL Mode 还可以实现对数据效验和转移等功能如: 
  1. 效验日期数据合法性. 
  2. 在INSERT或UPDATE过程中,如果被零除(或MOD(X,0)),则产生错误 
  3. 将‘"'视为识别符引号(‘`'引号字符) 
  4. 禁用反斜线字符(‘\')做为字符串内的退出字符。启用NO_BACKSLASH_ESCAPES模式,反斜线则成为普通字符。 
  5. 将||视为字符串连接操作符(+)(同CONCAT()),而不视为OR。

MYSQL大小写敏感介绍

数据库chris 发表了文章 • 0 个评论 • 295 次浏览 • 2017-05-08 22:55 • 来自相关话题

简介

在MySQL中,数据库对应数据目录中的目录。数据库中的每个表至少对应数据库目录中的一个文件(也可能是多个,取决于存储引擎)。因此,所使用操作系统的大小写敏感性决定了数据库名和表名的大小写敏感性。
 
在大多数Unix中数据库名和表名对大小写敏感,而在Windows中对大小写不敏感。一个显著的例外情况是Mac OS X,它基于Unix但使用默认文件系统类型(HFS+),对大小写不敏感。然而,Mac OS X也支持UFS卷,该卷对大小写敏感,就像Unix一样。
 
变量lower_case_file_system说明是否数据目录所在的文件系统对文件名的大小写敏感。ON说明对文件名的大小写不敏感,OFF表示敏感。
 
例如在Linux下查看:
mysql> show variables like 'lower%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| lower_case_file_system | OFF |
| lower_case_table_names | 0 |
+------------------------+-------+
2 rows in set (0.00 sec)说明Linux系统对大小写敏感,MySQL也默认设置为对大小写敏感, 而Windows则相反。
 

大小写区分规则

Linux下:
数据库名与表名是严格区分大小写的;表的别名是严格区分大小写的;列名与列的别名在所有的情况下均是忽略大小写的;变量名也是严格区分大小写的;
 
windows下:
都不区分大小写
 
Mac OS下(非UFS卷):
都不区分大小写
 

参数说明

unix下lower_case_table_names默认值为 0 ;  Windows下默认值是 1 ;Mac OS X下默认值是 2 .





由大小写敏感转换为不敏感方法

如果原来所建立库及表都是对大小写敏感的,想要转换为对大小写不敏感,主要需要进行如下3步:
将数据库数据通过mysqldump导出。在my.cnf中更改lower_case_tables_name = 1,并重启mysql数据库。将导出的数据导入mysql数据库。
 

注意事项

为了避免大小写引发的问题,一种推荐的命名规则是:在定义数据库、表、列的时候全部采用小写字母加下划线的方式,不使用任何大写字母
 
在任何系统中可以使用lower_case_tables_name=1。使用该选项的不利之处是当使用SHOW TABLES或SHOW DATABASES时,看不出名字原来是用大写还是小写。
 
请注意在Unix中如果以前lower_case_tables_name = 0将lower_case_tables_name设置为1之前,重启mysqld之前,必须先将旧的数据库名和表名转换为小写。 查看全部


简介


在MySQL中,数据库对应数据目录中的目录。数据库中的每个表至少对应数据库目录中的一个文件(也可能是多个,取决于存储引擎)。因此,所使用操作系统的大小写敏感性决定了数据库名和表名的大小写敏感性。
 
在大多数Unix中数据库名和表名对大小写敏感,而在Windows中对大小写不敏感。一个显著的例外情况是Mac OS X,它基于Unix但使用默认文件系统类型(HFS+),对大小写不敏感。然而,Mac OS X也支持UFS卷,该卷对大小写敏感,就像Unix一样。
 
变量lower_case_file_system说明是否数据目录所在的文件系统对文件名的大小写敏感。ON说明对文件名的大小写不敏感,OFF表示敏感。
 
例如在Linux下查看:
mysql> show variables like 'lower%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| lower_case_file_system | OFF |
| lower_case_table_names | 0 |
+------------------------+-------+
2 rows in set (0.00 sec)
说明Linux系统对大小写敏感,MySQL也默认设置为对大小写敏感, 而Windows则相反。
 


大小写区分规则


Linux下
  • 数据库名与表名是严格区分大小写的;
  • 表的别名是严格区分大小写的;
  • 列名与列的别名在所有的情况下均是忽略大小写的;
  • 变量名也是严格区分大小写的;

 
windows下
  • 都不区分大小写

 
Mac OS下(非UFS卷):
  • 都不区分大小写

 


参数说明


unix下lower_case_table_names默认值为 0 ;  Windows下默认值是 1 ;Mac OS X下默认值是 2 .
args.png


由大小写敏感转换为不敏感方法


如果原来所建立库及表都是对大小写敏感的,想要转换为对大小写不敏感,主要需要进行如下3步:
  1. 将数据库数据通过mysqldump导出。
  2. 在my.cnf中更改lower_case_tables_name = 1,并重启mysql数据库。
  3. 将导出的数据导入mysql数据库。

 


注意事项


为了避免大小写引发的问题,一种推荐的命名规则是:在定义数据库、表、列的时候全部采用小写字母加下划线的方式,不使用任何大写字母
 
在任何系统中可以使用lower_case_tables_name=1。使用该选项的不利之处是当使用SHOW TABLES或SHOW DATABASES时,看不出名字原来是用大写还是小写。
 
请注意在Unix中如果以前lower_case_tables_name = 0将lower_case_tables_name设置为1之前,重启mysqld之前,必须先将旧的数据库名和表名转换为小写。

Redis高可用架构之Sentinel

运维技术Geek小A 发表了文章 • 0 个评论 • 337 次浏览 • 2017-03-25 19:09 • 来自相关话题

一、背景​  
公司的业务在大量的使用redis,访问量大的业务我们有在使用codis集群,redis 3.0集群,说到redis 3.0集群,我们线上已经跑了半年多了,集群本身没有出现过任务问题,但是由于我们这个业务是海外的,集群建在aws的ec2上,由于ec2的网络抖动或者ec2本身的原因,导致主从切换,目前aws的技术正在跟进,这个集群目前的QPS 50w+,集群本身已经做到了高可用和横向扩展,但是,实际情况一些小的业务没必要上集群,单个实例就可以满足业务需求,那么我们就要想办法如何保证单个实例的高可用,最近也在看相关的文档,做一些测试,大家有在使用redis主从+lvs 漂VIP的方案,也有使用redis主从+哨兵 漂VIP的方案,甚至有在代码逻辑做故障切换等等,各种各样的方案都有,下面我介绍一下redis主从+ 哨兵 漂VIP的方案,后面我们打算线上大规模的使用这个方案。
 
二、环境
#redis
100.10.32.54:6400 主库
100.10.32.55:6400 从库
100.10.32.250 VIP

#sentinel
100.10.32.54:26400 sentinel 本地节点
100.10.32.55:26400 sentinel 本地节点
100.10.32.57:26400 sentinel 仲裁节点
三、部署
1、安装
yum -y install redis2、撰写redis配置文件(100.10.32.54 和100.10.32.55)
vim /etc/redis_6400.conf

daemonize yes
pidfile "/var/run/redis_6400.pid"
port 6400
tcp-backlog 65535
bind 0.0.0.0
timeout 0
tcp-keepalive 0
loglevel notice
logfile "/var/log/redis/redis_6400.log"
maxmemory 8gb
maxmemory-policy allkeys-lru
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename "dump.rdb"
dir "/data/redis/6400"
slave-serve-stale-data yes
slave-read-only yes
repl-disable-tcp-nodelay no
slave-priority 100
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 1283、撰写sentinel配置文件(100.10.32.54 、100.10.32.55 和100.10.32.57)
vim /etc/redis-sentinel6400.conf

daemonize yes
port 26400
dir "/data/redis/redis_sentinels"
pidfile "/var/run/redis/sentinel6400.pid"
logfile "/data/redis/redis_sentinels/sentinel6400.log"
sentinel monitor master6400 100.10.32.54 6400 2
sentinel down-after-milliseconds master6400 6000
sentinel failover-timeout master6400 18000
sentinel client-reconfig-script master6400 /opt/notify_master6400.sh ##仲裁节点无需添加这行配置,client-reconfig-script参数是在sentinel做failover的过程中调用脚本漂vip到新的master上PS:
关于sentinel 的一些工作原理和参数说明,请参阅:http://redisdoc.com/topic/sentinel.html  
 
4、撰写漂VIP的脚本(100.10.32.54 、100.10.32.55)
vim /opt/notify_master6400.sh

#!/bin/bash
MASTER_IP=$6
LOCAL_IP='100.10.32.54' #从库修改为100.10.32.55
VIP='100.10.32.250'
NETMASK='24'
INTERFACE='eth0'
if [ ${MASTER_IP} = ${LOCAL_IP} ]; then
/sbin/ip addr add ${VIP}/${NETMASK} dev ${INTERFACE}
/sbin/arping -q -c 3 -A ${VIP} -I ${INTERFACE}
exit 0
else
/sbin/ip addr del ${VIP}/${NETMASK} dev ${INTERFACE}
exit 0
fi
exit 1chmod +x /opt/notify_master6400.sh #赋予可执行权限PS:
这里大概说一下这个脚本的工作原理,sentinel在做failover的 过程中会传出6个参数,分别是<master-name>、 <role>、 <state>、 <from-ip>、 <from-port>、 <to-ip> 、<to-port>,其中第6个参数from-ip也就是新的master的ip,对应脚本中的MASTER_IP,下面的if判断大家应该都很了然了,如果MASTER_IP=LOCAL_IP,那就绑定VIP,反之删除VIP。
 
5、启动redis服务(100.10.32.54、100.10.32.55)
redis-server /etc/redis_6400.conf6、初始化主从(100.10.32.55)
redis-cli -p 6400 slaveof 10.10.32.54 64007、绑定VIP到主库(100.10.32.54)
/sbin/ip addr add 100.10.32.250/24 dev eth08、启动sentinel服务(100.10.32.54、100.10.32.55、100.10.32.57)
redis-server /etc/redis-sentinel6400.conf --sentinel至此,整个高可用方案已经搭建完成。
 
[root@localhost tmp]# redis-cli -h 100.10.32.54 -p 6400 info Replication
# Replication
role:master
connected_slaves:1
slave0:ip=100.10.32.55,port=6400,state=online,offset=72669,lag=1
master_repl_offset:72669
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:72668[root@localhost tmp]# redis-cli -h 100.10.32.54 -p 26400 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=master6400,status=ok,address=100.10.32.54:6400,slaves=1,sentinels=3[root@localhost tmp]# ip a |grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
inet 100.10.32.54/24 brd 100.10.32.255 scope global eth0
inet 100.10.32.250/24 scope global secondary eth0
四、测试
1、把主库停掉
redis-cli -h 100.10.32.54 -p 6400 shutdown2、看从库是否提升为主库
[root@localhost tmp]# redis-cli -h 100.10.32.55 -p 6400 info Replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0看VIP是否漂移到100.10.32.55上
[root@localhost tmp]# ip a |grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
inet 100.10.32.55/24 brd 100.10.32.255 scope global eth0
inet 100.10.32.250/24 scope global secondary eth04、看Sentinel的监控状态
[root@localhost tmp]# redis-cli -p 26400 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=master6400,status=ok,address=100.10.32.55:6400,slaves=1,sentinels=3原文链接:http://navyaijm.blog.51cto.com/4647068/1745569  
参考学习:http://www.cnblogs.com/LiZhiW/p/4851631.html  查看全部
一、背景​  
公司的业务在大量的使用redis,访问量大的业务我们有在使用codis集群,redis 3.0集群,说到redis 3.0集群,我们线上已经跑了半年多了,集群本身没有出现过任务问题,但是由于我们这个业务是海外的,集群建在aws的ec2上,由于ec2的网络抖动或者ec2本身的原因,导致主从切换,目前aws的技术正在跟进,这个集群目前的QPS 50w+,集群本身已经做到了高可用和横向扩展,但是,实际情况一些小的业务没必要上集群,单个实例就可以满足业务需求,那么我们就要想办法如何保证单个实例的高可用,最近也在看相关的文档,做一些测试,大家有在使用redis主从+lvs 漂VIP的方案,也有使用redis主从+哨兵 漂VIP的方案,甚至有在代码逻辑做故障切换等等,各种各样的方案都有,下面我介绍一下redis主从+ 哨兵 漂VIP的方案,后面我们打算线上大规模的使用这个方案。
 
二、环境
#redis
100.10.32.54:6400 主库
100.10.32.55:6400 从库
100.10.32.250 VIP

#sentinel
100.10.32.54:26400 sentinel 本地节点
100.10.32.55:26400 sentinel 本地节点
100.10.32.57:26400 sentinel 仲裁节点

三、部署
1、安装
yum -y install redis
2、撰写redis配置文件(100.10.32.54 和100.10.32.55)
vim /etc/redis_6400.conf

daemonize yes
pidfile "/var/run/redis_6400.pid"
port 6400
tcp-backlog 65535
bind 0.0.0.0
timeout 0
tcp-keepalive 0
loglevel notice
logfile "/var/log/redis/redis_6400.log"
maxmemory 8gb
maxmemory-policy allkeys-lru
databases 16
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename "dump.rdb"
dir "/data/redis/6400"
slave-serve-stale-data yes
slave-read-only yes
repl-disable-tcp-nodelay no
slave-priority 100
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-entries 512
list-max-ziplist-value 64
set-max-intset-entries 512
zset-max-ziplist-entries 128
3、撰写sentinel配置文件(100.10.32.54 、100.10.32.55 和100.10.32.57)
vim /etc/redis-sentinel6400.conf

daemonize yes
port 26400
dir "/data/redis/redis_sentinels"
pidfile "/var/run/redis/sentinel6400.pid"
logfile "/data/redis/redis_sentinels/sentinel6400.log"
sentinel monitor master6400 100.10.32.54 6400 2
sentinel down-after-milliseconds master6400 6000
sentinel failover-timeout master6400 18000
sentinel client-reconfig-script master6400 /opt/notify_master6400.sh ##仲裁节点无需添加这行配置,client-reconfig-script参数是在sentinel做failover的过程中调用脚本漂vip到新的master上
PS:
关于sentinel 的一些工作原理和参数说明,请参阅:http://redisdoc.com/topic/sentinel.html  
 
4、撰写漂VIP的脚本(100.10.32.54 、100.10.32.55)
vim /opt/notify_master6400.sh

#!/bin/bash
MASTER_IP=$6
LOCAL_IP='100.10.32.54' #从库修改为100.10.32.55
VIP='100.10.32.250'
NETMASK='24'
INTERFACE='eth0'
if [ ${MASTER_IP} = ${LOCAL_IP} ]; then
/sbin/ip addr add ${VIP}/${NETMASK} dev ${INTERFACE}
/sbin/arping -q -c 3 -A ${VIP} -I ${INTERFACE}
exit 0
else
/sbin/ip addr del ${VIP}/${NETMASK} dev ${INTERFACE}
exit 0
fi
exit 1
chmod +x /opt/notify_master6400.sh   #赋予可执行权限
PS:
这里大概说一下这个脚本的工作原理,sentinel在做failover的 过程中会传出6个参数,分别是<master-name>、 <role>、 <state>、 <from-ip>、 <from-port>、 <to-ip> 、<to-port>,其中第6个参数from-ip也就是新的master的ip,对应脚本中的MASTER_IP,下面的if判断大家应该都很了然了,如果MASTER_IP=LOCAL_IP,那就绑定VIP,反之删除VIP。
 
5、启动redis服务(100.10.32.54、100.10.32.55)
redis-server /etc/redis_6400.conf
6、初始化主从(100.10.32.55)
redis-cli -p 6400 slaveof 10.10.32.54 6400
7、绑定VIP到主库(100.10.32.54)
/sbin/ip addr add 100.10.32.250/24 dev eth0
8、启动sentinel服务(100.10.32.54、100.10.32.55、100.10.32.57)
redis-server /etc/redis-sentinel6400.conf --sentinel
至此,整个高可用方案已经搭建完成。
 
[root@localhost tmp]# redis-cli -h 100.10.32.54  -p 6400 info  Replication
# Replication
role:master
connected_slaves:1
slave0:ip=100.10.32.55,port=6400,state=online,offset=72669,lag=1
master_repl_offset:72669
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:72668
[root@localhost tmp]# redis-cli -h 100.10.32.54  -p 26400 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=master6400,status=ok,address=100.10.32.54:6400,slaves=1,sentinels=3
[root@localhost tmp]# ip a |grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
inet 100.10.32.54/24 brd 100.10.32.255 scope global eth0
inet 100.10.32.250/24 scope global secondary eth0

四、测试
1、把主库停掉
redis-cli -h 100.10.32.54  -p 6400 shutdown
2、看从库是否提升为主库
[root@localhost tmp]# redis-cli -h 100.10.32.55 -p 6400 info Replication
# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
看VIP是否漂移到100.10.32.55上
[root@localhost tmp]# ip a |grep eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
inet 100.10.32.55/24 brd 100.10.32.255 scope global eth0
inet 100.10.32.250/24 scope global secondary eth0
4、看Sentinel的监控状态
[root@localhost tmp]# redis-cli -p 26400 info  Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=master6400,status=ok,address=100.10.32.55:6400,slaves=1,sentinels=3
原文链接:http://navyaijm.blog.51cto.com/4647068/1745569  
参考学习:http://www.cnblogs.com/LiZhiW/p/4851631.html 

京东咚咚架构演进

运维技术koyo 发表了文章 • 0 个评论 • 641 次浏览 • 2016-08-24 22:26 • 来自相关话题

咚咚是什么?咚咚之于京东相当于旺旺之于淘宝,它们都是服务于买家和卖家的沟通。 自从京东开始为第三方卖家提供入驻平台服务后,咚咚也就随之诞生了。 我们首先看看它诞生之初是什么样的。
 

1.0 诞生(2010 - 2011)​

为了业务的快速上线,1.0 版本的技术架构实现是非常直接且简单粗暴的。 如何简单粗暴法?请看架构图,如下:




1.0 的功能十分简单,实现了一个 IM 的基本功能,接入、互通消息和状态。 另外还有客服功能,就是顾客接入咨询时的客服分配,按轮询方式把顾客分配给在线的客服接待。 用开源 Mina 框架实现了 TCP 的长连接接入,用 Tomcat Comet 机制实现了 HTTP 的长轮询服务。 而消息投递的实现是一端发送的消息临时存放在 Redis 中,另一端拉取的生产消费模型。

这个模型的做法导致需要以一种高频率的方式来轮询 Redis 遍历属于自己连接的关联会话消息。 这个模型很简单,简单包括多个层面的意思:理解起来简单;开发起来简单;部署起来也简单。 只需要一个 Tomcat 应用依赖一个共享的 Redis,简单的实现核心业务功能,并支持业务快速上线。

但这个简单的模型也有些严重的缺陷,主要是效率和扩展问题。 轮询的频率间隔大小基本决定了消息的延时,轮询越快延时越低,但轮询越快消耗也越高。 这个模型实际上是一个高功耗低效能的模型,因为不活跃的连接在那做高频率的无意义轮询。 高频有多高呢,基本在 100 ms 以内,你不能让轮询太慢,比如超过 2 秒轮一次,人就会在聊天过程中感受到明显的会话延迟。 随着在线人数增加,轮询的耗时也线性增长,因此这个模型导致了扩展能力和承载能力都不好,一定会随着在线人数的增长碰到性能瓶颈。

1.0 的时代背景正是京东技术平台从 .NET 向 Java 转型的年代,我也正是在这期间加入京东并参与了京东主站技术转型架构升级的过程。 之后开始接手了京东咚咚,并持续完善这个产品,进行了三次技术架构演进。
 

2.0 成长(2012)

我们刚接手时 1.0 已在线上运行并支持京东 POP(开放平台)业务,之后京东打算组建自营在线客服团队并落地在成都。 不管是自营还是 POP 客服咨询业务当时都起步不久,1.0 架构中的性能和效率缺陷问题还没有达到引爆的业务量级。 而自营客服当时还处于起步阶段,客服人数不足,服务能力不够,顾客咨询量远远超过客服的服务能力。 超出服务能力的顾客咨询,当时我们的系统统一返回提示客服繁忙,请稍后咨询。 这种状况导致高峰期大量顾客无论怎么刷新请求,都很可能无法接入客服,体验很差。 所以 2.0 重点放在了业务功能体验的提升上,如下图所示:




针对无法及时提供服务的顾客,可以排队或者留言。 针对纯文字沟通,提供了文件和图片等更丰富的表达方式。 另外支持了客服转接和快捷回复等方式来提升客服的接待效率。 总之,整个 2.0 就是围绕提升客服效率和用户体验。 而我们担心的效率问题在 2.0 高速发展业务的时期还没有出现,但业务量正在逐渐积累,我们知道它快要爆了。 到 2012 年末,度过双十一后开始了 3.0 的一次重大架构升级。
 

3.0 爆发(2013 - 2014)

经历了 2.0 时代一整年的业务高速发展,实际上代码规模膨胀的很快。 与代码一块膨胀的还有团队,从最初的 4 个人到近 30 人。 团队大了后,一个系统多人开发,开发人员层次不一,规范难统一,系统模块耦合重,改动沟通和依赖多,上线风险难以控制。 一个单独 tomcat 应用多实例部署模型终于走到头了,这个版本架构升级的主题就是服务化。

服务化的第一个问题如何把一个大的应用系统切分成子服务系统。 当时的背景是京东的部署还在半自动化年代,自动部署系统刚起步,子服务系统若按业务划分太细太多,部署工作量很大且难管理。 所以当时我们不是按业务功能分区服务的,而是按业务重要性级别划分了 0、1、2 三个级别不同的子业务服务系统。 另外就是独立了一组接入服务,针对不同渠道和通信方式的接入端,见下图。




更细化的应用服务和架构分层方式可见下图:




这次大的架构升级,主要考虑了三个方面:稳定性、效率和容量。 做了下面这些事情:
业务分级、核心、非核心业务隔离多机房部署,流量分流、容灾冗余、峰值应对冗余读库多源,失败自动转移写库主备,短暂有损服务容忍下的快速切换外部接口,失败转移或快速断路Redis 主备,失败转移大表迁移,MongoDB 取代 MySQL 存储消息记录改进消息投递模型
 
前 6 条基本属于考虑系统稳定性、可用性方面的改进升级。 这一块属于陆续迭代完成的,承载很多失败转移的配置和控制功能在上面图中是由管控中心提供的。 第 7 条主要是随着业务量的上升,单日消息量越来越大后,使用了 MongoDB 来单独存储量最大的聊天记录。 第 8 条是针对 1.0 版本消息轮询效率低的改进,改进后的投递方式如下图所示:




不再是轮询了,而是让终端每次建立连接后注册接入点位置,消息投递前定位连接所在接入点位置再推送过去。 这样投递效率就是恒定的了,而且很容易扩展,在线人数越多则连接数越多,只需要扩展接入点即可。 其实,这个模型依然还有些小问题,主要出在离线消息的处理上,可以先思考下,我们最后再讲。

3.0 经过了两年的迭代式升级,单纯从业务量上来说还可以继续支撑很长时间的增长。 但实际上到 2014 年底我们面对的不再是业务量的问题,而是业务模式的变化。 这直接导致了一个全新时代的到来。
 

4.0 涅槃(2015 至今 )

2014 年京东的组织架构发生了很大变化,从一个公司变成了一个集团,下设多个子公司。 原来的商城成为了其中一个子公司,新成立的子公司包括京东金融、京东智能、京东到家、拍拍、海外事业部等。 各自业务范围不同,业务模式也不同,但不管什么业务总是需要客服服务。 如何复用原来为商城量身订做的咚咚客服系统并支持其他子公司业务快速接入成为我们新的课题。

最早要求接入的是拍拍网,它是从腾讯收购的,所以是完全不同的账户和订单交易体系。 由于时间紧迫,我们把为商城订做的部分剥离,基于 3.0 架构对接拍拍又单独订做了一套,并独立部署,像下面这样。




虽然在业务要求的时间点前完成了上线,但这样做也带来了明显的问题:
复制工程,定制业务开发,多套源码维护成本高独立部署,至少双机房主备外加一个灰度集群,资源浪费大
 
以前我们都是面向业务去架构系统,如今新的业务变化形势下我们开始考虑面向平台去架构,在统一平台上跑多套业务,统一源码,统一部署,统一维护。 把业务服务继续拆分,剥离出最基础的 IM 服务,IM 通用服务,客服通用服务,而针对不同的业务特殊需求做最小化的定制服务开发。 部署方式则以平台形式部署,不同的业务方的服务跑在同一个平台上,但数据互相隔离。 服务继续被拆分的更微粒化,形成了一组服务矩阵(见下图)




而部署方式,只需要在双机房建立两套对等集群,并另外建一个较小的灰度发布集群即可,所有不同业务都运行在统一平台集群上,如下图:




更细粒度的服务意味着每个服务的开发更简单,代码量更小,依赖更少,隔离稳定性更高。 但更细粒度的服务也意味着更繁琐的运维监控管理,直到今年公司内部弹性私有云、缓存云、消息队列、部署、监控、日志等基础系统日趋完善, 使得实施这类细粒度划分的微服务架构成为可能,运维成本可控。 而从当初 1.0 的 1 种应用进程,到 3.0 的 6、7 种应用进程,再到 4.0 的 50+ 更细粒度的不同种应用进程。 每种进程再根据承载业务流量不同分配不同的实例数,真正的实例进程数会过千。 为了更好的监控和管理这些进程,为此专门定制了一套面向服务的运维管理系统,见下图:




统一服务运维提供了实用的内部工具和库来帮助开发更健壮的微服务。 包括中心配置管理,流量埋点监控,数据库和缓存访问,运行时隔离,如下图所示是一个运行隔离的图示:




细粒度的微服务做到了进程间隔离,严格的开发规范和工具库帮助实现了异步消息和异步 HTTP 来避免多个跨进程的同步长调用链。 进程内部通过切面方式引入了服务增强容器 Armor 来隔离线程, 并支持进程内的单独业务降级和同步转异步化执行。而所有这些工具和库服务都是为了两个目标:
让服务进程运行时状态可见让服务进程运行时状态可被管理和改变

最后我们回到前文留下的一个悬念,就是关于消息投递模型的缺陷。 一开始我们在接入层检测到终端连接断开后,消息无法投递,再将消息缓存下来,等终端重连接上来再拉取离线消息。 这个模型在移动时代表现的很不好,因为移动网络的不稳定性,导致经常断链后重连。 而准确的检测网络连接断开是依赖一个网络超时的,导致检测可能不准确,引发消息假投递成功。 新的模型如下图所示,它不再依赖准确的网络连接检测,投递前待确认消息 id 被缓存,而消息体被持久存储。 等到终端接收确认返回后,该消息才算投妥,未确认的消息 id 再重新登陆后或重连接后作为离线消息推送。 这个模型不会产生消息假投妥导致的丢失,但可能导致消息重复,只需由客户终端按消息 id 去重即可。




京东咚咚诞生之初正是京东技术转型到 Java 之时,经历这些年的发展,取得了很大的进步。 从草根走向专业,从弱小走向规模,从分散走向统一,从杂乱走向规范。 本文主要重心放在了几年来咚咚架构演进的过程,技术架构单独拿出来看我认为没有绝对的好与不好, 技术架构总是要放在彼时的背景下来看,要考虑业务的时效价值、团队的规模和能力、环境基础设施等等方面。 架构演进的生命周期适时匹配好业务的生命周期,才可能发挥最好的效果。
分享阅读原文:http://www.cnblogs.com/mindwind/p/5017591.html  查看全部
dongdong.png

咚咚是什么?咚咚之于京东相当于旺旺之于淘宝,它们都是服务于买家和卖家的沟通。 自从京东开始为第三方卖家提供入驻平台服务后,咚咚也就随之诞生了。 我们首先看看它诞生之初是什么样的。
 


1.0 诞生(2010 - 2011)​


为了业务的快速上线,1.0 版本的技术架构实现是非常直接且简单粗暴的。 如何简单粗暴法?请看架构图,如下:
Arch1.png

1.0 的功能十分简单,实现了一个 IM 的基本功能,接入、互通消息和状态。 另外还有客服功能,就是顾客接入咨询时的客服分配,按轮询方式把顾客分配给在线的客服接待。 用开源 Mina 框架实现了 TCP 的长连接接入,用 Tomcat Comet 机制实现了 HTTP 的长轮询服务。 而消息投递的实现是一端发送的消息临时存放在 Redis 中,另一端拉取的生产消费模型。

这个模型的做法导致需要以一种高频率的方式来轮询 Redis 遍历属于自己连接的关联会话消息。 这个模型很简单,简单包括多个层面的意思:理解起来简单;开发起来简单;部署起来也简单。 只需要一个 Tomcat 应用依赖一个共享的 Redis,简单的实现核心业务功能,并支持业务快速上线。

但这个简单的模型也有些严重的缺陷,主要是效率和扩展问题。 轮询的频率间隔大小基本决定了消息的延时,轮询越快延时越低,但轮询越快消耗也越高。 这个模型实际上是一个高功耗低效能的模型,因为不活跃的连接在那做高频率的无意义轮询。 高频有多高呢,基本在 100 ms 以内,你不能让轮询太慢,比如超过 2 秒轮一次,人就会在聊天过程中感受到明显的会话延迟。 随着在线人数增加,轮询的耗时也线性增长,因此这个模型导致了扩展能力和承载能力都不好,一定会随着在线人数的增长碰到性能瓶颈。

1.0 的时代背景正是京东技术平台从 .NET 向 Java 转型的年代,我也正是在这期间加入京东并参与了京东主站技术转型架构升级的过程。 之后开始接手了京东咚咚,并持续完善这个产品,进行了三次技术架构演进。
 


2.0 成长(2012)


我们刚接手时 1.0 已在线上运行并支持京东 POP(开放平台)业务,之后京东打算组建自营在线客服团队并落地在成都。 不管是自营还是 POP 客服咨询业务当时都起步不久,1.0 架构中的性能和效率缺陷问题还没有达到引爆的业务量级。 而自营客服当时还处于起步阶段,客服人数不足,服务能力不够,顾客咨询量远远超过客服的服务能力。 超出服务能力的顾客咨询,当时我们的系统统一返回提示客服繁忙,请稍后咨询。 这种状况导致高峰期大量顾客无论怎么刷新请求,都很可能无法接入客服,体验很差。 所以 2.0 重点放在了业务功能体验的提升上,如下图所示:
Arch2.png

针对无法及时提供服务的顾客,可以排队或者留言。 针对纯文字沟通,提供了文件和图片等更丰富的表达方式。 另外支持了客服转接和快捷回复等方式来提升客服的接待效率。 总之,整个 2.0 就是围绕提升客服效率和用户体验。 而我们担心的效率问题在 2.0 高速发展业务的时期还没有出现,但业务量正在逐渐积累,我们知道它快要爆了。 到 2012 年末,度过双十一后开始了 3.0 的一次重大架构升级。
 


3.0 爆发(2013 - 2014)


经历了 2.0 时代一整年的业务高速发展,实际上代码规模膨胀的很快。 与代码一块膨胀的还有团队,从最初的 4 个人到近 30 人。 团队大了后,一个系统多人开发,开发人员层次不一,规范难统一,系统模块耦合重,改动沟通和依赖多,上线风险难以控制。 一个单独 tomcat 应用多实例部署模型终于走到头了,这个版本架构升级的主题就是服务化。

服务化的第一个问题如何把一个大的应用系统切分成子服务系统。 当时的背景是京东的部署还在半自动化年代,自动部署系统刚起步,子服务系统若按业务划分太细太多,部署工作量很大且难管理。 所以当时我们不是按业务功能分区服务的,而是按业务重要性级别划分了 0、1、2 三个级别不同的子业务服务系统。 另外就是独立了一组接入服务,针对不同渠道和通信方式的接入端,见下图。
Arch3.png

更细化的应用服务和架构分层方式可见下图:
Arch4.png

这次大的架构升级,主要考虑了三个方面:稳定性、效率和容量。 做了下面这些事情:
  1. 业务分级、核心、非核心业务隔离
  2. 多机房部署,流量分流、容灾冗余、峰值应对冗余
  3. 读库多源,失败自动转移
  4. 写库主备,短暂有损服务容忍下的快速切换
  5. 外部接口,失败转移或快速断路
  6. Redis 主备,失败转移
  7. 大表迁移,MongoDB 取代 MySQL 存储消息记录
  8. 改进消息投递模型

 
前 6 条基本属于考虑系统稳定性、可用性方面的改进升级。 这一块属于陆续迭代完成的,承载很多失败转移的配置和控制功能在上面图中是由管控中心提供的。 第 7 条主要是随着业务量的上升,单日消息量越来越大后,使用了 MongoDB 来单独存储量最大的聊天记录。 第 8 条是针对 1.0 版本消息轮询效率低的改进,改进后的投递方式如下图所示:
Arch5.png

不再是轮询了,而是让终端每次建立连接后注册接入点位置,消息投递前定位连接所在接入点位置再推送过去。 这样投递效率就是恒定的了,而且很容易扩展,在线人数越多则连接数越多,只需要扩展接入点即可。 其实,这个模型依然还有些小问题,主要出在离线消息的处理上,可以先思考下,我们最后再讲。

3.0 经过了两年的迭代式升级,单纯从业务量上来说还可以继续支撑很长时间的增长。 但实际上到 2014 年底我们面对的不再是业务量的问题,而是业务模式的变化。 这直接导致了一个全新时代的到来。
 


4.0 涅槃(2015 至今 )


2014 年京东的组织架构发生了很大变化,从一个公司变成了一个集团,下设多个子公司。 原来的商城成为了其中一个子公司,新成立的子公司包括京东金融、京东智能、京东到家、拍拍、海外事业部等。 各自业务范围不同,业务模式也不同,但不管什么业务总是需要客服服务。 如何复用原来为商城量身订做的咚咚客服系统并支持其他子公司业务快速接入成为我们新的课题。

最早要求接入的是拍拍网,它是从腾讯收购的,所以是完全不同的账户和订单交易体系。 由于时间紧迫,我们把为商城订做的部分剥离,基于 3.0 架构对接拍拍又单独订做了一套,并独立部署,像下面这样。
Arch6.png

虽然在业务要求的时间点前完成了上线,但这样做也带来了明显的问题:
  1. 复制工程,定制业务开发,多套源码维护成本高
  2. 独立部署,至少双机房主备外加一个灰度集群,资源浪费大

 
以前我们都是面向业务去架构系统,如今新的业务变化形势下我们开始考虑面向平台去架构,在统一平台上跑多套业务,统一源码,统一部署,统一维护。 把业务服务继续拆分,剥离出最基础的 IM 服务,IM 通用服务,客服通用服务,而针对不同的业务特殊需求做最小化的定制服务开发。 部署方式则以平台形式部署,不同的业务方的服务跑在同一个平台上,但数据互相隔离。 服务继续被拆分的更微粒化,形成了一组服务矩阵(见下图)
Arch7.png

而部署方式,只需要在双机房建立两套对等集群,并另外建一个较小的灰度发布集群即可,所有不同业务都运行在统一平台集群上,如下图:
Arch8.png

更细粒度的服务意味着每个服务的开发更简单,代码量更小,依赖更少,隔离稳定性更高。 但更细粒度的服务也意味着更繁琐的运维监控管理,直到今年公司内部弹性私有云、缓存云、消息队列、部署、监控、日志等基础系统日趋完善, 使得实施这类细粒度划分的微服务架构成为可能,运维成本可控。 而从当初 1.0 的 1 种应用进程,到 3.0 的 6、7 种应用进程,再到 4.0 的 50+ 更细粒度的不同种应用进程。 每种进程再根据承载业务流量不同分配不同的实例数,真正的实例进程数会过千。 为了更好的监控和管理这些进程,为此专门定制了一套面向服务的运维管理系统,见下图:
Arch9.png

统一服务运维提供了实用的内部工具和库来帮助开发更健壮的微服务。 包括中心配置管理,流量埋点监控,数据库和缓存访问,运行时隔离,如下图所示是一个运行隔离的图示:
Arch10.png

细粒度的微服务做到了进程间隔离,严格的开发规范和工具库帮助实现了异步消息和异步 HTTP 来避免多个跨进程的同步长调用链。 进程内部通过切面方式引入了服务增强容器 Armor 来隔离线程, 并支持进程内的单独业务降级和同步转异步化执行。而所有这些工具和库服务都是为了两个目标:
  1. 让服务进程运行时状态可见
  2. 让服务进程运行时状态可被管理和改变


最后我们回到前文留下的一个悬念,就是关于消息投递模型的缺陷。 一开始我们在接入层检测到终端连接断开后,消息无法投递,再将消息缓存下来,等终端重连接上来再拉取离线消息。 这个模型在移动时代表现的很不好,因为移动网络的不稳定性,导致经常断链后重连。 而准确的检测网络连接断开是依赖一个网络超时的,导致检测可能不准确,引发消息假投递成功。 新的模型如下图所示,它不再依赖准确的网络连接检测,投递前待确认消息 id 被缓存,而消息体被持久存储。 等到终端接收确认返回后,该消息才算投妥,未确认的消息 id 再重新登陆后或重连接后作为离线消息推送。 这个模型不会产生消息假投妥导致的丢失,但可能导致消息重复,只需由客户终端按消息 id 去重即可。
Arch11.png

京东咚咚诞生之初正是京东技术转型到 Java 之时,经历这些年的发展,取得了很大的进步。 从草根走向专业,从弱小走向规模,从分散走向统一,从杂乱走向规范。 本文主要重心放在了几年来咚咚架构演进的过程,技术架构单独拿出来看我认为没有绝对的好与不好, 技术架构总是要放在彼时的背景下来看,要考虑业务的时效价值、团队的规模和能力、环境基础设施等等方面。 架构演进的生命周期适时匹配好业务的生命周期,才可能发挥最好的效果。
分享阅读原文:http://www.cnblogs.com/mindwind/p/5017591.html 

大型网站系统架构演化之路

运维技术being 发表了文章 • 0 个评论 • 1033 次浏览 • 2016-01-10 16:26 • 来自相关话题

前言

一个成熟的大型网站(如淘宝、天猫、腾讯等)的系统架构并不是一开始设计时就具备完整的高性能、高可用、高伸缩等特性的,它是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式、技术架构、设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统架构是随着业务的扩展而逐步完善的,并不是一蹴而就;不同业务特征的系统,会有各自的侧重点,例如淘宝要解决海量的商品信息的搜索、下单、支付;例如腾讯要解决数亿用户的实时消息传输;百度它要处理海量的搜索请求;他们都有各自的业务特性,系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下,找出其中共用的技术,这些技术和手段广泛运用在大型网站系统的架构中,下面就通过介绍大型网站系统的演化过程,来认识这些技术和手段。

一、最开始的网站架构

最初的架构,应用程序、数据库、文件都部署在一台服务器上,如图:





二、应用、数据、文件分离

随着业务的扩展,一台服务器已经不能满足性能需求,故将应用程序、数据库、文件各自部署在独立的服务器上,并且根据服务器的用途配置不同的硬件,达到最佳的性能效果。





三、利用缓存改善网站性能

在硬件优化性能的同时,同时也通过软件进行性能优化,在大部分的网站系统中,都会利用缓存技术改善系统的性能,使用缓存主要源于热点数据的存在,大部分网站访问都遵循28原则(即80%的访问请求,最终落在20%的数据上),所以我们可以对热点数据进行缓存,减少这些数据的访问路径,提高用户体验。




缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理等,这个后面再讲。本地缓存,顾名思义是将数据缓存在应用服务器本地,可以存在内存中,也可以存在文件,OSCache就是常用的本地缓存组件。本地缓存的特点是速度快,但因为本地空间有限所以缓存数据量也有限。分布式缓存的特点是,可以缓存海量的数据,并且扩展非常容易,在门户类网站中常常被使用,速度按理没有本地缓存快,常用的分布式缓存是Memcached、Redis。

四、使用集群改善应用服务器性能

应用服务器作为网站的入口,会承担大量的请求,我们往往通过应用服务器集群来分担请求数。应用服务器前面部署负载均衡服务器调度用户请求,根据分发策略将请求分发到多个应用服务器节点。




常用的负载均衡技术硬件的有F5,价格比较贵,软件的有LVS、Nginx、HAProxy。LVS是四层负载均衡,根据目标地址和端口选择内部服务器,Nginx和HAProxy是七层负载均衡,可以根据报文内容选择内部服务器,因此LVS分发路径优于Nginx和HAProxy,性能要高些,而Nginx和HAProxy则更具配置性,如可以用来做动静分离(根据请求报文特征,选择静态资源服务器还是应用服务器)。

五、数据库读写分离和分库分表

随着用户量的增加,数据库成为最大的瓶颈,改善数据库性能常用的手段是进行读写分离以及分库分表,读写分离顾名思义就是将数据库分为读库和写库,通过主备功能实现数据同步。分库分表则分为水平切分和垂直切分,水平切分则是对一个数据库特大的表进行拆分,例如用户表。垂直切分则是根据业务的不同来切分,如用户业务、商品业务相关的表放在不同的数据库中。





六、使用CDN和反向代理提高网站性能

假如我们的服务器都部署在成都的机房,对于四川的用户来说访问是较快的,而对于北京的用户访问是较慢的,这是由于四川和北京分别属于电信和联通的不同发达地区,北京用户访问需要通过互联路由器经过较长的路径才能访问到成都的服务器,返回路径也一样,所以数据传输时间比较长。对于这种情况,常常使用CDN解决,CDN将数据内容缓存到运营商的机房,用户访问时先从最近的运营商获取数据,这样大大减少了网络访问的路径。比较专业的CDN运营商有蓝汛、网宿。




而反向代理,则是部署在网站的机房,当用户请求达到时首先访问反向代理服务器,反向代理服务器将缓存的数据返回给用户,如果没有缓存数据才会继续访问应用服务器获取,这样做减少了获取数据的成本。反向代理有Squid,Nginx。

七、使用分布式文件系统

用户一天天增加,业务量越来越大,产生的文件越来越多,单台的文件服务器已经不能满足需求,这时就需要分布式文件系统的支撑。常用的分布式文件系统有GFS、HDFS、TFS。





八、使用NoSql和搜索引擎

对于海量数据的查询和分析,我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb、hbase、redis,搜索引擎有lucene、solr、elasticsearch。





九、将应用服务器进行业务拆分

随着业务进一步扩展,应用程序变得非常臃肿,这时我们需要将应用程序进行业务拆分,如百度分为新闻、网页、图片等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者共享数据库来实现。





十、搭建分布式服务

这时我们发现各个业务应用都会使用到一些基本的业务服务,例如用户服务、订单服务、支付服务、安全服务,这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分部式服务框架搭建分布式服务。阿里的Dubbo是一个不错的选择。





总结

大型网站的架构是根据业务需求不断完善的,根据不同的业务特征会做特定的设计和考虑,本文只是讲述一个常规大型网站会涉及的一些技术和手段。

分享阅读整理原文:http://www.cnblogs.com/leefreeman/p/3993449.html
参考书籍:《大型网站技术架构》《海量运维运营规划》 查看全部


前言


一个成熟的大型网站(如淘宝、天猫、腾讯等)的系统架构并不是一开始设计时就具备完整的高性能、高可用、高伸缩等特性的,它是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式、技术架构、设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统架构是随着业务的扩展而逐步完善的,并不是一蹴而就;不同业务特征的系统,会有各自的侧重点,例如淘宝要解决海量的商品信息的搜索、下单、支付;例如腾讯要解决数亿用户的实时消息传输;百度它要处理海量的搜索请求;他们都有各自的业务特性,系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下,找出其中共用的技术,这些技术和手段广泛运用在大型网站系统的架构中,下面就通过介绍大型网站系统的演化过程,来认识这些技术和手段。


一、最开始的网站架构


最初的架构,应用程序、数据库、文件都部署在一台服务器上,如图:
website_arch1.png


二、应用、数据、文件分离


随着业务的扩展,一台服务器已经不能满足性能需求,故将应用程序、数据库、文件各自部署在独立的服务器上,并且根据服务器的用途配置不同的硬件,达到最佳的性能效果。
website_arch2.png


三、利用缓存改善网站性能


在硬件优化性能的同时,同时也通过软件进行性能优化,在大部分的网站系统中,都会利用缓存技术改善系统的性能,使用缓存主要源于热点数据的存在,大部分网站访问都遵循28原则(即80%的访问请求,最终落在20%的数据上),所以我们可以对热点数据进行缓存,减少这些数据的访问路径,提高用户体验。
website_arch3.png

缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理等,这个后面再讲。本地缓存,顾名思义是将数据缓存在应用服务器本地,可以存在内存中,也可以存在文件,OSCache就是常用的本地缓存组件。本地缓存的特点是速度快,但因为本地空间有限所以缓存数据量也有限。分布式缓存的特点是,可以缓存海量的数据,并且扩展非常容易,在门户类网站中常常被使用,速度按理没有本地缓存快,常用的分布式缓存是Memcached、Redis。


四、使用集群改善应用服务器性能


应用服务器作为网站的入口,会承担大量的请求,我们往往通过应用服务器集群来分担请求数。应用服务器前面部署负载均衡服务器调度用户请求,根据分发策略将请求分发到多个应用服务器节点。
website_arch4.png

常用的负载均衡技术硬件的有F5,价格比较贵,软件的有LVS、Nginx、HAProxy。LVS是四层负载均衡,根据目标地址和端口选择内部服务器,Nginx和HAProxy是七层负载均衡,可以根据报文内容选择内部服务器,因此LVS分发路径优于Nginx和HAProxy,性能要高些,而Nginx和HAProxy则更具配置性,如可以用来做动静分离(根据请求报文特征,选择静态资源服务器还是应用服务器)。


五、数据库读写分离和分库分表


随着用户量的增加,数据库成为最大的瓶颈,改善数据库性能常用的手段是进行读写分离以及分库分表,读写分离顾名思义就是将数据库分为读库和写库,通过主备功能实现数据同步。分库分表则分为水平切分和垂直切分,水平切分则是对一个数据库特大的表进行拆分,例如用户表。垂直切分则是根据业务的不同来切分,如用户业务、商品业务相关的表放在不同的数据库中。
website_arch5.png


六、使用CDN和反向代理提高网站性能


假如我们的服务器都部署在成都的机房,对于四川的用户来说访问是较快的,而对于北京的用户访问是较慢的,这是由于四川和北京分别属于电信和联通的不同发达地区,北京用户访问需要通过互联路由器经过较长的路径才能访问到成都的服务器,返回路径也一样,所以数据传输时间比较长。对于这种情况,常常使用CDN解决,CDN将数据内容缓存到运营商的机房,用户访问时先从最近的运营商获取数据,这样大大减少了网络访问的路径。比较专业的CDN运营商有蓝汛、网宿。
website_arch6.png

而反向代理,则是部署在网站的机房,当用户请求达到时首先访问反向代理服务器,反向代理服务器将缓存的数据返回给用户,如果没有缓存数据才会继续访问应用服务器获取,这样做减少了获取数据的成本。反向代理有Squid,Nginx。


七、使用分布式文件系统


用户一天天增加,业务量越来越大,产生的文件越来越多,单台的文件服务器已经不能满足需求,这时就需要分布式文件系统的支撑。常用的分布式文件系统有GFS、HDFS、TFS。
website_arch7.png


八、使用NoSql和搜索引擎


对于海量数据的查询和分析,我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb、hbase、redis,搜索引擎有lucene、solr、elasticsearch。
website_arch8.png


九、将应用服务器进行业务拆分


随着业务进一步扩展,应用程序变得非常臃肿,这时我们需要将应用程序进行业务拆分,如百度分为新闻、网页、图片等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者共享数据库来实现。
website_arch9.png


十、搭建分布式服务


这时我们发现各个业务应用都会使用到一些基本的业务服务,例如用户服务、订单服务、支付服务、安全服务,这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分部式服务框架搭建分布式服务。阿里的Dubbo是一个不错的选择。
website_arch10.png


总结


大型网站的架构是根据业务需求不断完善的,根据不同的业务特征会做特定的设计和考虑,本文只是讲述一个常规大型网站会涉及的一些技术和手段。


分享阅读整理原文:http://www.cnblogs.com/leefreeman/p/3993449.html
参考书籍:《大型网站技术架构》《海量运维运营规划》


负载均衡LVS原理和应用详解

运维技术push 发表了文章 • 1 个评论 • 1323 次浏览 • 2016-01-01 19:03 • 来自相关话题

一、LB常用解决方案

1. 硬件负载均衡解决方案:
[]F5公司: BIG-IP[/][]Citrix公司: Netscaler[/][]A10公司: A10[/][]Array [/][]Redware[/]
2. Linux: LVS
完成Linux Virtual Server作者 (章文嵩,花名段正明)
ipvs工作于netfilter框架上
ipvs: 框架,工作在内核中,工作在input链上,需要依赖于规则完成转发。 如果发现发往本机INPUT链的请求,如果能匹配到集群规则,直接转发至post-routing链发出主机。 
规则: 简单来说就是把ip加端口定义为ipvs集群服务,ipvs会为此请求定义一个或多个后端服务目标地址未必会改,但是报文会被强行转发给后端的服务器。 
ipvs组件: ipvsadm(用户空间,用来编写规则) + ipvs(内核空间) 
ipvs工作在第四层: 
     1) 成为四层交换、四层路由。 做第四层转发。

     2) 只能基于ip和port转发,无法在应用层,session级别转发

     3) 不用到达应用层空间,就能转发

lvs 性能很好,但是由于只第四层,不能到用户空间,因此不能进行更加精细的控制。 在精细控制方面,haproxy和Ngnix可以更好的实现。 
lvs通常作为总入口,更精细化的切割可能使用,haproxy或者Nginx实现 
报文的信息流: CIP<–>VIP–DIP<–>RIP
     1) CIP: Client ip 

     2) VIP: virtual ip 

     3) DIP: Director IP 

     4) RIP: Real server Ip 

     客户端请求,被VIP端口接收后,从DIP接口被转发出去,并转发至RIP

二、LVS类型

1. NAT(dNAT)
    访问过程如下:

            1) CIP访问VIP 

            2) VIP接收报文后,做dNAT,指向某一个RIP 

            3) RIP拿到接收到报文后进行回应

            4) 此时需要,RIP网关指向DIP,也就是Director server. 否则若在互联网上,即便报文是可以回应给CIP客户端,但是由于CIP并没有请求RIP服务器,因此报文会被丢弃。 

        NAT特性:

            1) RS应该使用私有地址

            2) RS的网关必须指向DIP 

            3) RIP 和 DIP 必须在一同意网段内

            4) 进出的报文,无论请求还是响应,都必须经过Director Server, 请求报文由DS完成目标地址转换,响应报文由DS完成源地址转换 

            5) 在高负载应用场景中,DS很可能成为系统性能瓶颈。 

            6) 支持端口映射。

            7) 内部RS可以使用任意支持集群服务的任意操作系统。




 
 2. DR 
1)让前端路由将请求发往VIP时,只能是Dirctor上的VIP
     禁止RS响应对VIP的ARP广播请求:
            (1) 在前端路由上实现静态MAC地址VIP的绑定;

                前提:得有路由器的配置权限;

                缺点:Directory故障转时,无法更新此绑定;

            (2) arptables

                前提:在各RS在安装arptables程序,并编写arptables规则

                缺点:依赖于独特功能的应用程序

            (3) 修改Linux内核参数

                前提:RS必须是Linux;

                缺点:适用性差; 

    Linux的工作特性:IP地址是属于主机,而非某特定网卡;也就是说,主机上所有的网卡都会向外通告,需要先配置参数,然后配置IP,因为只要IP地址配置完成则开始想外通告mac地址为了使响应报文由配置有VIP的lo包装,使源地址为VIP,需要配置路由经过lo网卡的别名,最终由eth0发出

             两个参数的取值含义:

                    arp_announce:定义通告模式

                        0: default, 只要主机接入网络,则自动通告所有为网卡mac地址

                        1: 尽力不通告非直接连入网络的网卡mac地址

                        2: 只通告直接进入网络的网卡mac地址

                    arp_ignore:定义收到arp请求的时响应模式

                        0: 只有arp 广播请求,马上响应,并且响应所有本机网卡的mac地址

                        1: 只响应,接受arp广播请求的网卡接口mac地址

                        2: 只响应,接受arp广播请求的网卡接口mac地址,并且需要请求广播与接口地址属于同一网段

                        3: 主机范围(Scope host)内生效的接口,不予响应,只响应全局生效与外网能通信的网卡接口

                        4-7: 保留位

                        8: 不响应一切arp广播请求
    配置方法: 

                    全部网卡

                        arp_ignore 1

                        arp_announce 2 

                    同时再分别配置每个网卡,eth0和lo

                        arp_ignore 1

                        arp_annource 2
2) 特性
   (1)RS是可以使用公网地址,此时可以直接通过互联网连入,配置,监控RS服务器
   (2)RS的网不能指向DIP
   (3)RS跟DS要在同一物理网络内,最好在一同一网段内
   (4)请求报文经过Director但是相应报文不经过Director
   (5)不支持端口映射
   (6)RS可以使用,大多数的操作系统,至少要可以隐藏VIP








3. LVS TUN: IP隧道,IP报文中套IP报文 
        1)RIP,DIP,VIP都必须是公网地址

        2)RS网关不会指向DIP

        3)请求报文经过Director,但相应报文一定不经过Director

        4)不支持端口映射

        5)RS的OS必须得支持隧道功能




 4. FULLNAT: 必须内核打补丁才能使用,使得各RS主机可以跨vlan. 源IP和目标IP都修改。





三、LVS调度算法

1. 静态方法:仅根据算法本身进行调度

        rr: Round Robin

        wrr: Weighted RR

        sh: source hashing,源地址进行hash,然后分配到特定的服务器

        dh: destination hashing

            用于多前端防火墙的场景中,使得访问从一个防火墙进同时还从这个防火墙出来。 

2. 动态方法:根据算法及RS当前的负载状况

        lc: Least Connection

            Overhead=Active*256+Inactive

            结果中,最小者胜出;

        wlc: Weighted LC

            Overhead=(Active*256+Inactive)/weight

        sed: Shortest Expect Delay

            Overhead=(Active+1)*256/weight

        nq: Nerver Queue,在Sed基础上,开局时候先轮寻一圈。 

        lblc: Locality-based Least Connection (基于本地的最小连接) dh+lc

        lblcr: Replicated and Locality-based Least Connection 后端服务器是缓存服务器时, 可以绑定连接到某一缓存服务器中。

3. LVS缺陷: 

    不能检测后端服务器的健康状况,总是发送连接到后端。 

    Session持久机制:

        1、session绑定:始终将同一个请求者的连接定向至同一个RS(第一次请求时仍由调度方法选择);没有容错能力,有损均衡效果;

        2、session复制:在RS之间同步session,因此,每个RS持集群中所有的session;对于大规模集群环境不适用;

        3、session服务器:利用单独部署的服务器来统一管理session; 

四、ipvsadm使用方法

1.相关命令ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]] [-M netmask]
ipvsadm -D -t|u|f service-address
ipvsadm -C
ipvsadm -R
ipvsadm -S [-n]
ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight] [-x upper] [-y lower]
ipvsadm -d -t|u|f service-address -r server-address
ipvsadm -L|l [options]
ipvsadm -Z [-t|u|f service-address] 2. 集群服务相关 -A: 添加一个集群服务
-t: tcp
-u: udp
-f: firewall mark,
通常用于将两个或以上的服务绑定为一个服务进行处理时使用
例如httpd和https
iptables mongo表一起使用

service-address:
-t IP:port
-u ip:port
-f firewall_mark

-s 调度方法,默认为wlc
-p timeout: persistent connection, 持久连接
-E 修改定义过的集群服务
-D -t|u|f service-address:删除指定的集群服务 3. RS相关 -a:向指定的Cluster services中添加RS
-t|-u|-f service-address:指明将RS添加至哪个Cluster Service中
-r: 指定RS,可包含{IP[:port]},只有支持端口映射的LVS类型才允许此处使用跟集群服务中不同的端口
LVS类型:
-g: Gateway模式,就是DR模型(默认)
-i: ipip模式,TUN模型
-m: masquerade地址伪装自动完成后半段的原地址转换,NAT
指定RS权重:
-w # 省略权重为1
-e: 修改指定的RS属性
-d -t|u|f service-address -r server-address:从指定的集群服务中删除某RS4. 清空所有的集群服务:-C5. 保存规则:(使用输出重定向)ipvsadm-save
ipvsadm -S6. 载入指定的规则:(使用输入重定向)ipvsadm-restore
ipvsadm -R 7. 查看ipvs规则等 -L [options]
-n: 数字格式显示IP地址
-c: 显示连接数相关信息
--stats: 显示统计数据
--rate: 速率
--exact:显示统计数据的精确值
--timeout: 超时时间
-Z: 计数器清零

五、LVS NAT模型的实现

[list=1]
[*]集群环境: 一台Director, 两台后端Real Server RS1,RS2 Director: 两网卡 [/*]
[/list] eth0: 192.168.98.133/24
eth1: 172.25.136.10/24
eth0:1: 192.168.98.128/24 作为VIP地址

RS1:
eth0: 172.25.136.11

RS2:
eth0: 172.25.136.12; Director的eth1和RS1,RS2的eth0在模拟在同一物理网络内,使用VMnet2
物理机windows 7 作为客户端,在192.168.98.0网络内2. 为RS添加网关指向Director RS1:
# ifconfig eth0 172.25.136.11/24
# route add default gw 172.25.136.10
RS2:
# ifconfig eth0 172.25.136.12/24
# route add default gw 172.25.136.10
添加完路由条目后,应该可以ping通Director 192.168.98.0网段的两个地址。3. 修改内核参数,开启转发功能# echo 1 > /proc/sys/net/ipv4/ip_forward 4. 在RS1和RS2上面创建测试页,并在Director验证服务 RS1上
# echo 'web from RS1' > /var/www/html/index.html
# service httpd start
RS2上
# echo 'web from RS2' > /var/www/html/index.html
# service httpd start
Director上验证
# curl 172.25.136.11
web from RS1
# curl 172.25.136.12
web from RS25. 在Director添加集群服务 # ipvsadm -A -t 192.168.98.128:80 -s wlc
# ipvsadm -a -t 192.168.98.128:80 -r 172.25.136.11:80 -m -w 1
# ipvsadm -a -t 192.168.98.128:80 -r 172.25.136.12:80 -m -w 36. 通过物理机浏览器访问192.168.98.128, 正常情况,就可以看到轮寻的两个RS的主页了。  访问几次后,查看统计数据如下,大概接入报文比例3:1, 说明wlc生效了
# ipvsadm -L --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP 192.168.98.128:http 45 227 227 32215 19245
-> 136-11.priv25.nus.edu.sg:htt 12 62 62 8571 6055
-> 136-12.priv25.nus.edu.sg:htt 33 165 165 23644 13190

六、LVS DR模型,当DIP,VIP,RIP都为公网地址时(实验环境中,把这三个地址全部放在同一物理网络中)

[list=1]
[*]地址规划: Director: [/*]
[/list] eth0: 192.168.98.133 作为ssh通信地址
eth0:1: 192.168.98.128 作为VIP, 可以进行浮动
RS1:
eth0: 192.168.98.129/24 作为RIP1
lo:1 : 192.168.98.128 作为隐藏的VIP
RS1:
eth0: 192.168.98.130 作为RIP2
lo:2: 192.168.98.128 作为隐藏VIP 2. 配置地址  Director:
# ifconfig eth0 192.168.98.133/24 up
# ifconfig eth0:1 192.168.98.128/24 up
RS1
# ifconfig eth0 192.168.98.129/24 up
RS2
# ifconfig eth0 192.168.98.130/25 up3. 修改RS1,RS3的内核参数,关闭lo的arp通告和lo的arp响应,并配置隐藏地址 RS1:
# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
# echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
# echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
设置RS1的隐藏VIP地址, 并禁止其向外发广播
# ifconfig lo:1 192.168.98.128 netmask 255.255.255.255 broadcast 192.168.98.128
RS2:
# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
# echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
# echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
设置RS2的隐藏VIP地址,并禁止其向外发广播
# ifconfig lo:1 192.168.98.128 netmask 255.255.255.255 broadcast 192.168.98.1284. 为RS1和RS2添加路由条目,保证其发出报文经过eth0之前,还要先经过lo:1 VIP, 使得源地址成为VIP RS1:
# route add 192.168.98.128 dev lo:1
RS2:
# route add 192.168.98.128 dev lo:15. 此时在Director上面添加,集群服务 # ipvsadm -A -t 192.168.98.128:80 -s wlc
# ipvsadm -a -t 192.168.98.128:80 -r 192.168.98.129:80 -g -w 1
# ipvsadm -a -t 192.168.98.128:80 -r 192.168.98.130:80 -g -w 3

七、LVS持久连接

[list=1]
[*]PCC:将来自于同一个客户端发往VIP的所有请求统统定向至同一个RS 可以通过修改轮寻算法为sh算法实现[/*]
[/list] # ipvsadm -E -t 192.168.98.128:80 -s sh
[root@www ~]# curl 192.168.98.128
eb from RS2
[root@www ~]# curl 192.168.98.128
web from RS2
[root@www ~]# curl 192.168.98.128
web from RS2
[root@www ~]# curl 192.168.98.128
web from RS2
[root@www ~]# curl 192.168.98.128
web from RS2
[root@www ~]# curl 192.168.98.128
web from RS2 2. PPC:将来自于一个客户端发往某VIP的某端口的所有请求统统定向至同一个RS;

[list=1]
[*]PFMC: 端口绑定,port affinity, 基于防火墙标记,将两个或以上的端口绑定为同一个服务 防火墙打标记[/*]
[/list] # iptables -t mangle -A PREROUTING -d VIP -p tcp --dport CS_Port -j MARK --set-mark # (0-99)
定义集群服务:
# ipvsadm -A -f #(防火墙打的标记)转载阅读,原文地址:负载均衡LVS原理及其应用 查看全部


一、LB常用解决方案


1. 硬件负载均衡解决方案:
    []F5公司: BIG-IP[/][]Citrix公司: Netscaler[/][]A10公司: A10[/][]Array [/][]Redware[/]

2. Linux: LVS
  1. 完成Linux Virtual Server作者 (章文嵩,花名段正明)

  1. ipvs工作于netfilter框架上

  1. ipvs: 框架,工作在内核中,工作在input链上,需要依赖于规则完成转发。 如果发现发往本机INPUT链的请求,如果能匹配到集群规则,直接转发至post-routing链发出主机。 

  1. 规则: 简单来说就是把ip加端口定义为ipvs集群服务,ipvs会为此请求定义一个或多个后端服务目标地址未必会改,但是报文会被强行转发给后端的服务器。 

  1. ipvs组件: ipvsadm(用户空间,用来编写规则) + ipvs(内核空间) 

  1. ipvs工作在第四层: 

     1) 成为四层交换、四层路由。 做第四层转发。

     2) 只能基于ip和port转发,无法在应用层,session级别转发

     3) 不用到达应用层空间,就能转发

  1. lvs 性能很好,但是由于只第四层,不能到用户空间,因此不能进行更加精细的控制。 在精细控制方面,haproxy和Ngnix可以更好的实现。 

  1. lvs通常作为总入口,更精细化的切割可能使用,haproxy或者Nginx实现 

  1. 报文的信息流: CIP<–>VIP–DIP<–>RIP

     1) CIP: Client ip 

     2) VIP: virtual ip 

     3) DIP: Director IP 

     4) RIP: Real server Ip 

     客户端请求,被VIP端口接收后,从DIP接口被转发出去,并转发至RIP


二、LVS类型


1. NAT(dNAT)
    访问过程如下:

            1) CIP访问VIP 

            2) VIP接收报文后,做dNAT,指向某一个RIP 

            3) RIP拿到接收到报文后进行回应

            4) 此时需要,RIP网关指向DIP,也就是Director server. 否则若在互联网上,即便报文是可以回应给CIP客户端,但是由于CIP并没有请求RIP服务器,因此报文会被丢弃。 

        NAT特性:

            1) RS应该使用私有地址

            2) RS的网关必须指向DIP 

            3) RIP 和 DIP 必须在一同意网段内

            4) 进出的报文,无论请求还是响应,都必须经过Director Server, 请求报文由DS完成目标地址转换,响应报文由DS完成源地址转换 

            5) 在高负载应用场景中,DS很可能成为系统性能瓶颈。 

            6) 支持端口映射。

            7) 内部RS可以使用任意支持集群服务的任意操作系统。
lvs_nat.png

 
 2. DR 
1)让前端路由将请求发往VIP时,只能是Dirctor上的VIP
     禁止RS响应对VIP的ARP广播请求:
            (1) 在前端路由上实现静态MAC地址VIP的绑定;

                前提:得有路由器的配置权限;

                缺点:Directory故障转时,无法更新此绑定;

            (2) arptables

                前提:在各RS在安装arptables程序,并编写arptables规则

                缺点:依赖于独特功能的应用程序

            (3) 修改Linux内核参数

                前提:RS必须是Linux;

                缺点:适用性差; 

    Linux的工作特性:IP地址是属于主机,而非某特定网卡;也就是说,主机上所有的网卡都会向外通告,需要先配置参数,然后配置IP,因为只要IP地址配置完成则开始想外通告mac地址为了使响应报文由配置有VIP的lo包装,使源地址为VIP,需要配置路由经过lo网卡的别名,最终由eth0发出

             两个参数的取值含义:

                    arp_announce:定义通告模式

                        0: default, 只要主机接入网络,则自动通告所有为网卡mac地址

                        1: 尽力不通告非直接连入网络的网卡mac地址

                        2: 只通告直接进入网络的网卡mac地址

                    arp_ignore:定义收到arp请求的时响应模式

                        0: 只有arp 广播请求,马上响应,并且响应所有本机网卡的mac地址

                        1: 只响应,接受arp广播请求的网卡接口mac地址

                        2: 只响应,接受arp广播请求的网卡接口mac地址,并且需要请求广播与接口地址属于同一网段

                        3: 主机范围(Scope host)内生效的接口,不予响应,只响应全局生效与外网能通信的网卡接口

                        4-7: 保留位

                        8: 不响应一切arp广播请求
    配置方法: 

                    全部网卡

                        arp_ignore 1

                        arp_announce 2 

                    同时再分别配置每个网卡,eth0和lo

                        arp_ignore 1

                        arp_annource 2

2) 特性
   (1)RS是可以使用公网地址,此时可以直接通过互联网连入,配置,监控RS服务器
   (2)RS的网不能指向DIP
   (3)RS跟DS要在同一物理网络内,最好在一同一网段内
   (4)请求报文经过Director但是相应报文不经过Director
   (5)不支持端口映射
   (6)RS可以使用,大多数的操作系统,至少要可以隐藏VIP
lvs_dr_1.png

lvs_dr_2.png

3. LVS TUN: IP隧道,IP报文中套IP报文 
        1)RIP,DIP,VIP都必须是公网地址

        2)RS网关不会指向DIP

        3)请求报文经过Director,但相应报文一定不经过Director

        4)不支持端口映射

        5)RS的OS必须得支持隧道功能
lvs_lun.png

 4. FULLNAT: 必须内核打补丁才能使用,使得各RS主机可以跨vlan. 源IP和目标IP都修改
full_nat.png


三、LVS调度算法


1. 静态方法:仅根据算法本身进行调度

        rr: Round Robin

        wrr: Weighted RR

        sh: source hashing,源地址进行hash,然后分配到特定的服务器

        dh: destination hashing

            用于多前端防火墙的场景中,使得访问从一个防火墙进同时还从这个防火墙出来。 

2. 动态方法:根据算法及RS当前的负载状况

        lc: Least Connection

            Overhead=Active*256+Inactive

            结果中,最小者胜出;

        wlc: Weighted LC

            Overhead=(Active*256+Inactive)/weight

        sed: Shortest Expect Delay

            Overhead=(Active+1)*256/weight

        nq: Nerver Queue,在Sed基础上,开局时候先轮寻一圈。 

        lblc: Locality-based Least Connection (基于本地的最小连接) dh+lc

        lblcr: Replicated and Locality-based Least Connection 后端服务器是缓存服务器时, 可以绑定连接到某一缓存服务器中。

3. LVS缺陷: 

    不能检测后端服务器的健康状况,总是发送连接到后端。 

    Session持久机制:

        1、session绑定:始终将同一个请求者的连接定向至同一个RS(第一次请求时仍由调度方法选择);没有容错能力,有损均衡效果;

        2、session复制:在RS之间同步session,因此,每个RS持集群中所有的session;对于大规模集群环境不适用;

        3、session服务器:利用单独部署的服务器来统一管理session; 


四、ipvsadm使用方法


1.相关命令
ipvsadm -A|E -t|u|f service-address [-s scheduler] [-p [timeout]] [-M netmask]    
ipvsadm -D -t|u|f service-address
ipvsadm -C
ipvsadm -R
ipvsadm -S [-n]
ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight] [-x upper] [-y lower]
ipvsadm -d -t|u|f service-address -r server-address
ipvsadm -L|l [options]
ipvsadm -Z [-t|u|f service-address]
 2. 集群服务相关
    -A: 添加一个集群服务
-t: tcp
-u: udp
-f: firewall mark,
通常用于将两个或以上的服务绑定为一个服务进行处理时使用
例如httpd和https
iptables mongo表一起使用

service-address:
-t IP:port
-u ip:port
-f firewall_mark

-s 调度方法,默认为wlc
-p timeout: persistent connection, 持久连接
-E 修改定义过的集群服务
-D -t|u|f service-address:删除指定的集群服务
 3. RS相关
        -a:向指定的Cluster services中添加RS
-t|-u|-f service-address:指明将RS添加至哪个Cluster Service中
-r: 指定RS,可包含{IP[:port]},只有支持端口映射的LVS类型才允许此处使用跟集群服务中不同的端口
LVS类型:
-g: Gateway模式,就是DR模型(默认)
-i: ipip模式,TUN模型
-m: masquerade地址伪装自动完成后半段的原地址转换,NAT
指定RS权重:
-w # 省略权重为1
-e: 修改指定的RS属性
-d -t|u|f service-address -r server-address:从指定的集群服务中删除某RS
4. 清空所有的集群服务:
-C
5. 保存规则:(使用输出重定向)
ipvsadm-save 
ipvsadm -S
6. 载入指定的规则:(使用输入重定向)
ipvsadm-restore
ipvsadm -R
 7. 查看ipvs规则等
    -L [options]
-n: 数字格式显示IP地址
-c: 显示连接数相关信息
--stats: 显示统计数据
--rate: 速率
--exact:显示统计数据的精确值
--timeout: 超时时间
-Z: 计数器清零


五、LVS NAT模型的实现


[list=1]
[*]集群环境: 一台Director, 两台后端Real Server RS1,RS2
    Director: 两网卡    [/*]
[/list] eth0: 192.168.98.133/24
eth1: 172.25.136.10/24
eth0:1: 192.168.98.128/24 作为VIP地址

RS1:
eth0: 172.25.136.11

RS2:
eth0: 172.25.136.12;
    Director的eth1和RS1,RS2的eth0在模拟在同一物理网络内,使用VMnet2    
物理机windows 7 作为客户端,在192.168.98.0网络内
2. 为RS添加网关指向Director
    RS1:    
# ifconfig eth0 172.25.136.11/24
# route add default gw 172.25.136.10
RS2:
# ifconfig eth0 172.25.136.12/24
# route add default gw 172.25.136.10
添加完路由条目后,应该可以ping通Director 192.168.98.0网段的两个地址。
3. 修改内核参数,开启转发功能
# echo 1 > /proc/sys/net/ipv4/ip_forward
 4. 在RS1和RS2上面创建测试页,并在Director验证服务
    RS1上
# echo 'web from RS1' > /var/www/html/index.html
# service httpd start
RS2上
# echo 'web from RS2' > /var/www/html/index.html
# service httpd start
Director上验证
# curl 172.25.136.11
web from RS1
# curl 172.25.136.12
web from RS2
5. 在Director添加集群服务
    # ipvsadm -A -t 192.168.98.128:80 -s wlc    
# ipvsadm -a -t 192.168.98.128:80 -r 172.25.136.11:80 -m -w 1
# ipvsadm -a -t 192.168.98.128:80 -r 172.25.136.12:80 -m -w 3
6. 通过物理机浏览器访问192.168.98.128, 正常情况,就可以看到轮寻的两个RS的主页了。 
    访问几次后,查看统计数据如下,大概接入报文比例3:1, 说明wlc生效了    
# ipvsadm -L --stats
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Conns InPkts OutPkts InBytes OutBytes
-> RemoteAddress:Port
TCP 192.168.98.128:http 45 227 227 32215 19245
-> 136-11.priv25.nus.edu.sg:htt 12 62 62 8571 6055
-> 136-12.priv25.nus.edu.sg:htt 33 165 165 23644 13190


六、LVS DR模型,当DIP,VIP,RIP都为公网地址时(实验环境中,把这三个地址全部放在同一物理网络中)


[list=1]
[*]地址规划:
    Director:     [/*]
[/list] eth0: 192.168.98.133 作为ssh通信地址
eth0:1: 192.168.98.128 作为VIP, 可以进行浮动
RS1:
eth0: 192.168.98.129/24 作为RIP1
lo:1 : 192.168.98.128 作为隐藏的VIP
RS1:
eth0: 192.168.98.130 作为RIP2
lo:2: 192.168.98.128 作为隐藏VIP
 2. 配置地址 
    Director: 
# ifconfig eth0 192.168.98.133/24 up
# ifconfig eth0:1 192.168.98.128/24 up
RS1
# ifconfig eth0 192.168.98.129/24 up
RS2
# ifconfig eth0 192.168.98.130/25 up
3. 修改RS1,RS3的内核参数,关闭lo的arp通告和lo的arp响应,并配置隐藏地址
    RS1: 
# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
# echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
# echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
设置RS1的隐藏VIP地址, 并禁止其向外发广播
# ifconfig lo:1 192.168.98.128 netmask 255.255.255.255 broadcast 192.168.98.128
RS2:
# echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce
# echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
# echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
# echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
设置RS2的隐藏VIP地址,并禁止其向外发广播
# ifconfig lo:1 192.168.98.128 netmask 255.255.255.255 broadcast 192.168.98.128
4. 为RS1和RS2添加路由条目,保证其发出报文经过eth0之前,还要先经过lo:1 VIP, 使得源地址成为VIP
    RS1:     
# route add 192.168.98.128 dev lo:1
RS2:
# route add 192.168.98.128 dev lo:1
5. 此时在Director上面添加,集群服务
    # ipvsadm -A -t 192.168.98.128:80 -s wlc    
# ipvsadm -a -t 192.168.98.128:80 -r 192.168.98.129:80 -g -w 1
# ipvsadm -a -t 192.168.98.128:80 -r 192.168.98.130:80 -g -w 3


七、LVS持久连接


[list=1]
[*]PCC:将来自于同一个客户端发往VIP的所有请求统统定向至同一个RS
    可以通过修改轮寻算法为sh算法实现[/*]
[/list] # ipvsadm -E -t 192.168.98.128:80 -s sh
[root@www ~]# curl 192.168.98.128
eb from RS2
[root@www ~]# curl 192.168.98.128
web from RS2
[root@www ~]# curl 192.168.98.128
web from RS2
[root@www ~]# curl 192.168.98.128
web from RS2
[root@www ~]# curl 192.168.98.128
web from RS2
[root@www ~]# curl 192.168.98.128
web from RS2
 2. PPC:将来自于一个客户端发往某VIP的某端口的所有请求统统定向至同一个RS;

[list=1]
[*]PFMC: 端口绑定,port affinity, 基于防火墙标记,将两个或以上的端口绑定为同一个服务
    防火墙打标记[/*]
[/list] # iptables -t mangle -A PREROUTING -d VIP -p tcp --dport CS_Port -j MARK --set-mark # (0-99)
定义集群服务:
# ipvsadm -A -f #(防火墙打的标记)
转载阅读,原文地址:负载均衡LVS原理及其应用

mysql创建和删除表

数据库Ansible 发表了文章 • 0 个评论 • 1069 次浏览 • 2015-06-26 19:15 • 来自相关话题

创建表
简单的方式:CREATE TABLE person (
number INT(11),
name VARCHAR(255),
birthday DATE
);或者是CREATE TABLE IF NOT EXISTS person (
number INT(11),
name VARCHAR(255),
birthday DATE
);
查看mysql创建表:> SHOW CREATE table person;

CREATE TABLE `person` (
`number` int(11) DEFAULT NULL,
`name` varchar(255) DEFAULT NULL,
`birthday` date DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
查看表所有的列:> SHOW FULL COLUMNS from person;
+----------+--------------+-----------------+------+-----+---------+-------+---------------------------------+---------+
| Field | Type | Collation | Null | Key | Default | Extra | Privileges | Comment |
+----------+--------------+-----------------+------+-----+---------+-------+---------------------------------+---------+
| number | int(11) | NULL | YES | | NULL | | select,insert,update,references | |
| name | varchar(255) | utf8_general_ci | YES | | NULL | | select,insert,update,references | |
| birthday | date | NULL | YES | | NULL | | select,insert,update,references | |
+----------+--------------+-----------------+------+-----+---------+-------+---------------------------------+---------+
创建临时表CREATE TEMPORARY TABLE temp_person (
number INT(11),
name VARCHAR(255),
birthday DATE
);

在创建表格时,您可以使用TEMPORARY关键词。只有在当前连接情况下,TEMPORARY表才是可见的。当连接关闭时,TEMPORARY表被自动取消。这意味着两个不同的连接可以使用相同的临时表名称,同时两个临时表不会互相冲突,也不与原有的同名的非临时表冲突。(原有的表被隐藏,直到临时表被取消时为止。)您必须拥有CREATE TEMPORARY TABLES权限,才能创建临时表。

如果表已存在,则使用关键词IF NOT EXISTS可以防止发生错误。CREATE TABLE IF NOT EXISTS person2 (
number INT(11),
name VARCHAR(255),
birthday DATE
);

注意,原有表的结构与CREATE TABLE语句中表示的表的结构是否相同,这一点没有验证。注释:如果您在CREATE TABLE...SELECT语句中使用IF NOT EXISTS,则不论表是否已存在,由SELECT部分选择的记录都会被插入

在CREATE TABLE语句的末尾添加一个SELECT语句,在一个表的基础上创建表CREATE TABLE new_tbl SELECT [i] FROM orig_tbl;注意,用SELECT语句创建的列附在表的右侧,而不是覆盖在表上mysql> SELECT [/i] FROM foo;
+---+
| n |
+---+
| 1 |
+---+
mysql> CREATE TABLE bar (m INT) SELECT n FROM foo;
mysql> SELECT * FROM bar;
+------+---+
| m | n |
+------+---+
| NULL | 1 |
+------+---+也可以明确地为一个已生成的列指定类型CREATE TABLE foo (a TINYINT NOT NULL) SELECT b+1 AS a FROM bar;根据其它表的定义(包括在原表中定义的所有的列属性和索引),使用LIKE创建一个空表:CREATE TABLE new_tbl LIKE orig_tbl; 创建一个有主键,唯一索引,普通索引的表:CREATE TABLE `people` (
`peopleid` smallint(6) NOT NULL AUTO_INCREMENT,
`firstname` char(50) NOT NULL,
`lastname` char(50) NOT NULL,
`age` smallint(6) NOT NULL,
`townid` smallint(6) NOT NULL,
PRIMARY KEY (`peopleid`),
UNIQUE KEY `unique_fname_lname`(`firstname`,`lastname`),
KEY `fname_lname_age` (`firstname`,`lastname`,`age`)
) ;其中peopleid是主键,以firstname和lastname两列建立了一个唯一索引,以firstname,lastname,age三列建立了一个普通索引
 
删除表
 DROP TABLE tbl_name;

或者是

DROP TABLE IF EXISTS tbl_name;清空表数据
TRUNCATE TABLE table_name 查看全部
创建表
简单的方式:
CREATE TABLE person (
number INT(11),
name VARCHAR(255),
birthday DATE
);
或者是
CREATE TABLE IF NOT EXISTS person (
number INT(11),
name VARCHAR(255),
birthday DATE
);

查看mysql创建表:
> SHOW CREATE table person;

CREATE TABLE `person` (
`number` int(11) DEFAULT NULL,
`name` varchar(255) DEFAULT NULL,
`birthday` date DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

查看表所有的列:
> SHOW FULL COLUMNS from person;
+----------+--------------+-----------------+------+-----+---------+-------+---------------------------------+---------+
| Field | Type | Collation | Null | Key | Default | Extra | Privileges | Comment |
+----------+--------------+-----------------+------+-----+---------+-------+---------------------------------+---------+
| number | int(11) | NULL | YES | | NULL | | select,insert,update,references | |
| name | varchar(255) | utf8_general_ci | YES | | NULL | | select,insert,update,references | |
| birthday | date | NULL | YES | | NULL | | select,insert,update,references | |
+----------+--------------+-----------------+------+-----+---------+-------+---------------------------------+---------+

创建临时表
CREATE TEMPORARY TABLE temp_person (
number INT(11),
name VARCHAR(255),
birthday DATE
);


在创建表格时,您可以使用TEMPORARY关键词。只有在当前连接情况下,TEMPORARY表才是可见的。当连接关闭时,TEMPORARY表被自动取消。这意味着两个不同的连接可以使用相同的临时表名称,同时两个临时表不会互相冲突,也不与原有的同名的非临时表冲突。(原有的表被隐藏,直到临时表被取消时为止。)您必须拥有CREATE TEMPORARY TABLES权限,才能创建临时表。


如果表已存在,则使用关键词IF NOT EXISTS可以防止发生错误。
CREATE TABLE IF NOT EXISTS person2 (
number INT(11),
name VARCHAR(255),
birthday DATE
);


注意,原有表的结构与CREATE TABLE语句中表示的表的结构是否相同,这一点没有验证。注释:如果您在CREATE TABLE...SELECT语句中使用IF NOT EXISTS,则不论表是否已存在,由SELECT部分选择的记录都会被插入


在CREATE TABLE语句的末尾添加一个SELECT语句,在一个表的基础上创建表
CREATE TABLE new_tbl SELECT [i] FROM orig_tbl;
注意,用SELECT语句创建的列附在表的右侧,而不是覆盖在表上
mysql> SELECT [/i] FROM foo;
+---+
| n |
+---+
| 1 |
+---+
mysql> CREATE TABLE bar (m INT) SELECT n FROM foo;
mysql> SELECT * FROM bar;
+------+---+
| m | n |
+------+---+
| NULL | 1 |
+------+---+
也可以明确地为一个已生成的列指定类型
CREATE TABLE foo (a TINYINT NOT NULL) SELECT b+1 AS a FROM bar;
根据其它表的定义(包括在原表中定义的所有的列属性和索引),使用LIKE创建一个空表:
CREATE TABLE new_tbl LIKE orig_tbl;
 创建一个有主键,唯一索引,普通索引的表:
CREATE TABLE `people` (
`peopleid` smallint(6) NOT NULL AUTO_INCREMENT,
`firstname` char(50) NOT NULL,
`lastname` char(50) NOT NULL,
`age` smallint(6) NOT NULL,
`townid` smallint(6) NOT NULL,
PRIMARY KEY (`peopleid`),
UNIQUE KEY `unique_fname_lname`(`firstname`,`lastname`),
KEY `fname_lname_age` (`firstname`,`lastname`,`age`)
) ;
其中peopleid是主键,以firstname和lastname两列建立了一个唯一索引,以firstname,lastname,age三列建立了一个普通索引
 
删除表
 
DROP TABLE  tbl_name;

或者是

DROP TABLE IF EXISTS tbl_name;
清空表数据
TRUNCATE TABLE table_name

知乎技术方案初探

运维技术Ansible 发表了文章 • 0 个评论 • 647 次浏览 • 2016-05-03 13:54 • 来自相关话题

知乎的整个网站架构图如下:




知乎是国内很少的使用Python开发的一个网站,也很多值得我们学习的地方,从知乎让我们也可以了解到一些新的WEB技术。
 
一、Python框架
知乎目前使用的是Tornado框架。Tornado 全称Tornado Web Server,是一个用Python 语言写成的Web 服务器兼Web 应用框架,由 FriendFeed 公司在自己的网站FriendFeed 中使用,被facebook 收购以后框架以开源软件形式开放给大众。
参考链接:http://zh.wikipedia.org/wiki/Tornado 
学习文档:http://www.tornadoweb.cn/documentation 
 
二、数据库
目前知乎采用的是MySQL作为主要的存储,使用SqlAlchemy 为ORM进行数据库的建模或者映射。
 
三、缓存技术
知乎使用Redis来进行缓存、队列、计数或者任务,使用Redis-py为其连接客户端。
Redis参考链接:http://redis.readthedocs.org/en/latest/index.html 
Redis-Py参考链接:http://redis-py.readthedocs.org/en/latest/index.html
 
四、Javascript框架
知乎使用Google的Closure Library作为前端的JavaScript 框架。
 
五、负载处理
目前知乎使用的是nginx做反向代理,用nginx来做静态文件等大数据量的I/O操作。
 
六、图片服务
知乎以前用到的Upyun,现在已经迁移到知乎自己建的图片服务上。
 
七、邮件服务
知乎的邮件发送一开始使用的是Amazon的SES,由于SES有些功能不能满足需求,目前已经转换成Mailgun。
 
八、消息系统
知乎消息系统采用的是comet实现,comet是基于http长连接的“服务器推”技术。
 
九、虚拟环境
作为一个Python网站,知乎很有可能采用Virutalenv来解决纯净的包环境问题。中文文档地址:http://virtualenv-chinese-docs.readthedocs.org/en/latest/index.html
 
十、代码部署
常见的Python项目基本上采用Fabric进行部署,不知道知乎到底用的是哪一个。
 
十一、搜索实现
知乎使用mmseg做中文分词,对应的词根存在redis中作为key,数据库id作为value,每个数据项是一个zset集合。查询时根据key找到对应的value。
 
分享阅读原文:http://www.biaodianfu.com/zhihu-technique.html 查看全部
知乎的整个网站架构图如下:
zh.jpg

知乎是国内很少的使用Python开发的一个网站,也很多值得我们学习的地方,从知乎让我们也可以了解到一些新的WEB技术。
 
一、Python框架
知乎目前使用的是Tornado框架。Tornado 全称Tornado Web Server,是一个用Python 语言写成的Web 服务器兼Web 应用框架,由 FriendFeed 公司在自己的网站FriendFeed 中使用,被facebook 收购以后框架以开源软件形式开放给大众。
参考链接:http://zh.wikipedia.org/wiki/Tornado 
学习文档:http://www.tornadoweb.cn/documentation 
 
二、数据库
目前知乎采用的是MySQL作为主要的存储,使用SqlAlchemy 为ORM进行数据库的建模或者映射。
 
三、缓存技术
知乎使用Redis来进行缓存、队列、计数或者任务,使用Redis-py为其连接客户端。
Redis参考链接:http://redis.readthedocs.org/en/latest/index.html 
Redis-Py参考链接:http://redis-py.readthedocs.org/en/latest/index.html
 
四、Javascript框架
知乎使用Google的Closure Library作为前端的JavaScript 框架。
 
五、负载处理
目前知乎使用的是nginx做反向代理,用nginx来做静态文件等大数据量的I/O操作。
 
六、图片服务
知乎以前用到的Upyun,现在已经迁移到知乎自己建的图片服务上。
 
七、邮件服务
知乎的邮件发送一开始使用的是Amazon的SES,由于SES有些功能不能满足需求,目前已经转换成Mailgun
 
八、消息系统
知乎消息系统采用的是comet实现,comet是基于http长连接的“服务器推”技术。
 
九、虚拟环境
作为一个Python网站,知乎很有可能采用Virutalenv来解决纯净的包环境问题。中文文档地址:http://virtualenv-chinese-docs.readthedocs.org/en/latest/index.html
 
十、代码部署
常见的Python项目基本上采用Fabric进行部署,不知道知乎到底用的是哪一个。
 
十一、搜索实现
知乎使用mmseg做中文分词,对应的词根存在redis中作为key,数据库id作为value,每个数据项是一个zset集合。查询时根据key找到对应的value。
 
分享阅读原文:http://www.biaodianfu.com/zhihu-technique.html

CDN加速助力高并发网站架构

运维技术chris 发表了文章 • 0 个评论 • 760 次浏览 • 2016-04-18 00:15 • 来自相关话题

部署图

部署设计图如下:




架构说明:
用户通过互联网访问网站需要经过的节点如下:
一、要通过域名解析
在域名解析处有两种方式
1、自建,自建需要在域名解析前架设防火墙。

2、使用现有的域名解析提供商,需要设置成CNAME,其实就是另一个域名解析,进行跳转。在刚开始的时候建议先用CNAME方式,部署不影响用户现有方式,容易被用户接受,而且不用暂时不用担心第一级dns的问题。

总之,如果要建设idc加速,防止ddos攻击之类的服务,域名解析服务一定要提供,不管是直接提供dns服务还是间接通过cname转发。
里面的主要技术,是通过用户请求的ip来得到离用户最近的服务器的地址,并通过它来提供服务。如果要进行安全防护,比如sql注入检查,js跨站脚本等可以在这一层进行处理。
 
二、提供虚拟机
虚拟机现在主流有两种方式,一是虚拟主机,主要的软件有开源的openvz,商用的Virtuozzo等,另一类是虚拟机如vmware、xen、kvm等,这类提供虚拟操作系统,可以是异构的。他们两个的对比主要是虚拟主机的利用率比较高,可以一台主流pcserver可以虚拟几十个到上百个虚拟主机,但只能是同一类操作系统。虚拟机的运行效率相对低很多,一般主流pcserver也就十几个左右。他的有点是异构操作系统,备份管理比较方便。当然在建设的时候可以先用虚拟机,然后在虚拟机上建设虚拟主机。
 
如果要提供对外服务,ip地址是比不可少的,对于一个用户来说,一个域名需要几个点,就需要几个ip。
 
三、LVS集群
由于要提供加速等服务,用户直接使用的openvz虚拟主机的性能和效率一般不大,又要提供高可用性,所以需要通过虚拟主机访问lvs集群的数据,通过lvs集群来提供服务。
 
四、Squid
Squid是缓存,尤其是对静态页面和文件有很好加速效果。sina、sohu等都用它来做缓存加速。
 
五、Nginx​
Nginx主要提供反向代理功能,当通过修改或者更新了页面,由nginx来负责更新缓存。还有就是动态网站,也是由nginx来提供服务。
 
Nginx和sqid都可以提供静态缓存功能,两者还要结合起来发挥最大效果。如果要进行安全防护,比如sql注入检查,js跨站脚本等可以在这一层进行处理。

防DDOS

防ddos的主要内容由两个方面:
一、带宽这个是恨重要的地方,据我现在从网上得到的资料,现在主流的idc机房一般最大提供独立百兆端口,而且价格不菲。在这种情况下可以机柜租用。这个还需要调研是否可以提供更大的带宽。
 
二、防火墙设备
需要在接入口部署防火墙,需要根据idc接口端口来确定容量,有的idc机房也提供此服务。

三、流量牵引设备
这个一般idc机房会提供此服务,这个根据需要是否需要购买。 查看全部


部署图


部署设计图如下:
jg.png

架构说明:
用户通过互联网访问网站需要经过的节点如下:
一、要通过域名解析
在域名解析处有两种方式
1、自建,自建需要在域名解析前架设防火墙。

2、使用现有的域名解析提供商,需要设置成CNAME,其实就是另一个域名解析,进行跳转。在刚开始的时候建议先用CNAME方式,部署不影响用户现有方式,容易被用户接受,而且不用暂时不用担心第一级dns的问题。

总之,如果要建设idc加速,防止ddos攻击之类的服务,域名解析服务一定要提供,不管是直接提供dns服务还是间接通过cname转发。
里面的主要技术,是通过用户请求的ip来得到离用户最近的服务器的地址,并通过它来提供服务。如果要进行安全防护,比如sql注入检查,js跨站脚本等可以在这一层进行处理。
 
二、提供虚拟机
虚拟机现在主流有两种方式,一是虚拟主机,主要的软件有开源的openvz,商用的Virtuozzo等,另一类是虚拟机如vmware、xen、kvm等,这类提供虚拟操作系统,可以是异构的。他们两个的对比主要是虚拟主机的利用率比较高,可以一台主流pcserver可以虚拟几十个到上百个虚拟主机,但只能是同一类操作系统。虚拟机的运行效率相对低很多,一般主流pcserver也就十几个左右。他的有点是异构操作系统,备份管理比较方便。当然在建设的时候可以先用虚拟机,然后在虚拟机上建设虚拟主机。
 
如果要提供对外服务,ip地址是比不可少的,对于一个用户来说,一个域名需要几个点,就需要几个ip。
 
三、LVS集群
由于要提供加速等服务,用户直接使用的openvz虚拟主机的性能和效率一般不大,又要提供高可用性,所以需要通过虚拟主机访问lvs集群的数据,通过lvs集群来提供服务。
 
四、Squid
Squid是缓存,尤其是对静态页面和文件有很好加速效果。sina、sohu等都用它来做缓存加速。
 
五、Nginx​
Nginx主要提供反向代理功能,当通过修改或者更新了页面,由nginx来负责更新缓存。还有就是动态网站,也是由nginx来提供服务。
 
Nginx和sqid都可以提供静态缓存功能,两者还要结合起来发挥最大效果。如果要进行安全防护,比如sql注入检查,js跨站脚本等可以在这一层进行处理。


防DDOS


防ddos的主要内容由两个方面:
一、带宽这个是恨重要的地方,据我现在从网上得到的资料,现在主流的idc机房一般最大提供独立百兆端口,而且价格不菲。在这种情况下可以机柜租用。这个还需要调研是否可以提供更大的带宽。
 
二、防火墙设备
需要在接入口部署防火墙,需要根据idc接口端口来确定容量,有的idc机房也提供此服务。

三、流量牵引设备
这个一般idc机房会提供此服务,这个根据需要是否需要购买。

自动立体化运维监控理念

运维技术push 发表了文章 • 0 个评论 • 825 次浏览 • 2016-03-16 23:47 • 来自相关话题

场景

客户投诉有问题,于是研发测试运维开始投入定位和分析问题。A 研发去查日志,但是线上机器好多,一台一台的看, 日志文件太大,网速又慢,只能干等......B 研发同学觉得数据库可能有问题,但是自己又不能直接操作数据库,只能找DBA,但是DBA正好不在......C 运维同学更头大,一边要应付研发和测试的各种问题,一边还要自己查机器CPU、内存、io、网络、程序 状态,而且还那么多机器

解决方案

这种情况就需要一套“立体化、自动化、可视化的监控”,具体实现如下:
1、立体化
将故障分析和定位时涉及的所有的相关信息都要监控起来,共分为5层




(1)业务层收集和分析业务层的访问量、成功率等指标,例如当系统被刷的时候,业务层能够一目了然的看出访问量 会增加很多。(2)应用服务层以URI为维度的分析,可以看到某个URI的访问量、HTTP响应码分布、HTTP响应时间等指标应用服务层与业务层并不是一一对应的关系,一个业务可能对应多个应用服务层的URI,一个URI也可能对应多个业务层的业务(3)接口调用层接口调用层指的是系统依赖的外部系统接口,收集的信息包括访问情况,包括时延、错误码、次数等,当外部系统故障导致我们的业务故障时,通过接口调用层就能够快速的定位具体问题(4)基础组件层基础组件层指系统依赖的底层组件,例如容器、数据库、缓存、消息队列不同的组件收集的信息不一样,例如数据库MySQL的监控指标包括连接数、请求数、查询行数、更新行数等,而缓存包括 使用率、踢出率、命中率等(5)基础设施层基础设施层指操作系统状态、网络状态,收集的信息,包括cpu使用率、内存使用率、网卡流量、连接数等2、自动化不要再由人工去分析日志或者执行命令了,而是由程序自动完成这些动作当故障定位的时候需要这些信息时,可以立即看到,节省故障定位时间为此我们开发了一套数据收集和分析系统,这套系统可以从其它各个系统(包括业务系统、运维系统等)获取并分析数据,例如日志数据、状态数据等数据自动化收集和分析系统的结构如下:Logstash用于采集日志,redis用于缓存日志,elasticsearch用于存储和分析日志



3、可视化故障定位所需要的信息能够通过图表和数字直观的展示出来有了自动化的收集和分析作为基础,可视化只需要将数据做成图表展示即可除此以外,同比、环比这类数据也可以通过系统直观的展示出来,方便快速判断问题所在




内容整理自"面向业务的立体化高可用架构设计"
作者李运华 阿里资深工程师 查看全部


场景


客户投诉有问题,于是研发测试运维开始投入定位和分析问题。
A 研发去查日志,但是线上机器好多,一台一台的看, 日志文件太大,网速又慢,只能干等......
B 研发同学觉得数据库可能有问题,但是自己又不能直接操作数据库,只能找DBA,但是DBA正好不在......
C 运维同学更头大,一边要应付研发和测试的各种问题,一边还要自己查机器CPU、内存、io、网络、程序 状态,而且还那么多机器


解决方案


这种情况就需要一套“立体化、自动化、可视化的监控”,具体实现如下:
1、立体化
将故障分析和定位时涉及的所有的相关信息都要监控起来,共分为5层
ywc.png

(1)业务层
收集和分析业务层的访问量、成功率等指标,例如当系统被刷的时候,业务层能够一目了然的看出访问量 会增加很多。
(2)应用服务层
以URI为维度的分析,可以看到某个URI的访问量、HTTP响应码分布、HTTP响应时间等指标
应用服务层与业务层并不是一一对应的关系,一个业务可能对应多个应用服务层的URI,一个URI也可能对应多个业务层的业务
(3)接口调用层
接口调用层指的是系统依赖的外部系统接口,收集的信息包括访问情况,包括时延、错误码、次数等,当外部系统故障导致我们的业务故障时,通过接口调用层就能够快速的定位具体问题
(4)基础组件层
基础组件层指系统依赖的底层组件,例如容器、数据库、缓存、消息队列
不同的组件收集的信息不一样,例如数据库MySQL的监控指标包括连接数、请求数、查询行数、更新行数等,而缓存包括 使用率、踢出率、命中率等
(5)基础设施层
基础设施层指操作系统状态、网络状态,收集的信息,包括cpu使用率、内存使用率、网卡流量、连接数等
2、自动化
不要再由人工去分析日志或者执行命令了,而是由程序自动完成这些动作
当故障定位的时候需要这些信息时,可以立即看到,节省故障定位时间
为此我们开发了一套数据收集和分析系统,这套系统可以从其它各个系统(包括业务系统、运维系统等)获取并分析数据,例如日志数据、状态数据等
数据自动化收集和分析系统的结构如下:
Logstash用于采集日志,redis用于缓存日志,elasticsearch用于存储和分析日志
logarch.png

3、可视化
故障定位所需要的信息能够通过图表和数字直观的展示出来
有了自动化的收集和分析作为基础,可视化只需要将数据做成图表展示即可
除此以外,同比、环比这类数据也可以通过系统直观的展示出来,方便快速判断问题所在
ksh.png


内容整理自"面向业务的立体化高可用架构设计"
作者李运华 阿里资深工程师


创业公司技术架构详解

运维技术Rock 发表了文章 • 0 个评论 • 940 次浏览 • 2016-03-10 23:06 • 来自相关话题

提纲

[]产品[/][]技术[/][]数据[/][]运维[/]

创业

核心:以产品为核心团队人数:初创团队人数控制在10人以下,最佳是5,6人左右 技术选型:成熟技术,简洁高效解决问题 目标:快速完成beta 版本上线

产品中心

[]Axure做产品原型;[/][]直接画草图 [/]
一切以简单为指标,能说明问题就行。

语言框架

[]linux+apache(nginx)+mysql+php(CodeIgniter ,Symfony...) [/][]uwsgi+python(Django,Tornado,Pyramid...) [/][]mongodb+nodejs(Express...)[/][]java[/]

十万级PV

二台机器部署系统,传统web系统,LAMP。




百万PV






移动系统问题

[]与传统web相比,移动出现多版本(1.0,2.0,3.0...),以及版本升级问题[/][]网络不稳定(3g,wifi)[/]

开源软件

负载均衡:lvs、haproxy、nginx前端缓存代理:squid、varnish、ATSweb server :apache、nginx、Tomcatcache:memcached、redis 关系型数据库:mysql、postgresql 文档型数据库:mongodb nosql:Tokyo Cabinet、leveldb全文检索:sphinx、lucene、solr 分布式搜索引擎:elasticsearch 中文分词:mmseg、ictclas爬虫采集:scrapy监控系统:nagios、cacti、zabbix 、Ganglia推荐系统:mahout消息队列:: zeroMQ、RabbitMQ、Kafka异步作业队列:gearman 分布式文件系统:fastdfs、moosefs 项目管理:JIRA知识共享:wiki、Confluence代码管理:git、svn移动统计数据:countly 分布式计算存储:mapreduce、hadoop还有好多好多,就不一一介绍了!

移动初始架构














统计数据可视化和推荐系统






监控






架构感悟

[]没有一层不变的架构,随着业务发展而变化 [/][]业务不同,架构不同,发现问题解决问题 [/][]保持简洁[/][]易于扩展,容错[/] 查看全部


提纲


    []产品[/][]技术[/][]数据[/][]运维[/]


创业


核心:以产品为核心
团队人数:初创团队人数控制在10人以下,最佳是5,6人左右 
技术选型:成熟技术,简洁高效解决问题 
目标:快速完成beta 版本上线


产品中心


    []Axure做产品原型;[/][]直接画草图 [/]

一切以简单为指标,能说明问题就行。


语言框架


    []linux+apache(nginx)+mysql+php(CodeIgniter ,Symfony...) [/][]uwsgi+python(Django,Tornado,Pyramid...) [/][]mongodb+nodejs(Express...)[/][]java[/]


十万级PV


二台机器部署系统,传统web系统,LAMP。
bw.png


百万PV


bbw.png


移动系统问题


    []与传统web相比,移动出现多版本(1.0,2.0,3.0...),以及版本升级问题[/][]网络不稳定(3g,wifi)[/]


开源软件


负载均衡:lvs、haproxy、nginx
前端缓存代理:squid、varnish、ATS
web server :apache、nginx、Tomcat
cache:memcached、redis 
关系型数据库:mysql、postgresql 
文档型数据库:mongodb 
nosql:Tokyo Cabinet、leveldb
全文检索:sphinx、lucene、solr 
分布式搜索引擎:elasticsearch 
中文分词:mmseg、ictclas
爬虫采集:scrapy
监控系统:nagios、cacti、zabbix 、Ganglia
推荐系统:mahout
消息队列:: zeroMQ、RabbitMQ、Kafka
异步作业队列:gearman 
分布式文件系统:fastdfs、moosefs 
项目管理:JIRA
知识共享:wiki、Confluence
代码管理:git、svn
移动统计数据:countly 
分布式计算存储:mapreduce、hadoop
还有好多好多,就不一一介绍了!


移动初始架构


mobarch.png

cd.png

insearch.png


统计数据可视化和推荐系统


view.png


监控


monitor.png


架构感悟


    []没有一层不变的架构,随着业务发展而变化 [/][]业务不同,架构不同,发现问题解决问题 [/][]保持简洁[/][]易于扩展,容错[/]

私有云架构行业云介绍

运维技术Rock 发表了文章 • 0 个评论 • 1043 次浏览 • 2016-02-29 23:40 • 来自相关话题

顾客就是上帝

传统的行业IT架构实现“云”化的过程多是基于现有业务系统采用为虚拟化,并辅之以资源池化等措施,渐渐构建为一个完整的私有云系统。由于各行业的业务系统差异较大,私有云落地过程中总会遇到这样那样的问题。作为一个技术人,将从私有云在典型行业的典型部门中落地的过程中,简述厂商在虚拟化方面很有可能遇到的痛点。

政务

政企中的桌面按职能划分包括办公、财务等,而这些正是桌面云的期望场景。加之目前国内政企在一些关键项目上非常乐意采用国内虚拟化产品,这也就给国内的IT厂商带来了机遇。场景分析:政企中的私有云,尤其是虚拟化部分近些年来一直在进行尝试性地推广。下面我以需求最直接的桌面云进行叙述。



用户桌面:面向办公的桌面,一般需求为Mircosoft Office、邮件处理等文字密集型软件;通信类软件一般为国内厂商开发的非广域网通信软件以及QQ;防病毒软件种类比较多,目前卡巴斯基、诺顿等占 多,360使用较少;影音类软件使用局限于网页flash,或者国内厂商定制的流媒体客户端。对于财务桌面,需求除普通办公桌面外也有一些财务类软件,而这些软件对桌面负荷较普通办公桌面会高出一定量的资源消耗,同时也会有U-Key、指纹 仪等终端设备,所以对于这类桌面,我们一般进行特殊设置,比如将其固定到某台服务器上运行,并赋予一定优先级,保证资源优先分配。在普通桌面与财务桌面以外,也有浮动桌面可供出差人员或者来访人员临时使用,此种桌面与一般办公桌面无异,但可能要求有严格的用户检查控制以及无状态模式要求,防止恶意使用导致损失。系统维护:政企中的网络管理人员一般为具有一定计算机水平的专业人士,并且他们在部门里推广办公桌面的时候起着很重要的作用。所以我们首先获得他们对产品的认可,解决他们在现有架构中遇到的管理困难。 不管在哪种场景中,管理人员对产品的认可,都是产品价值的体现之一 。安全保障:政务IT系统中的安全模块在系统的每个层次里都有体现,包括桌面、网络、交换设备、服务器、操作系统等,同时也可能会与其他基础设备连接,每个模块 相对独立又保持联系。一般在涉及安全的场景中,我们会采取服务端镜像加密和其他一系列的安全保障工作,兼顾性能和安全的同时保证桌面体验,这点在以后的章 节中会有所阐述。虚拟化融合架构:物理机与虚拟机同时提供服务的模式已经不是什么新东西了,早些年就已经有一大批使用虚拟服务器的政企客户,但涉及的产品基本以国外产品为主。随着国 产化的一系列强制措施和美国对华的服务器CPU的禁售,国产品牌才开始崭露头角。在一些服务器消耗量比较大的政企客户中,也渐渐地在周边业务系统上使用国 产虚拟化产品。我相信在未来几年内,国内虚拟化厂商会在政务云的服务器虚拟化中会占有很大比例,并且是不可替代的重要组成。痛点----->文件监控:谈政务云,多数标书中都会提到的一点就是文件监控。一般虚拟化厂商在这方面积累较少,使用fs-notify去开发有一定开发量,所以多数人会使用 第三方产品进行集成。国内常用的文件监控方法即使用Windows文件系统事件通知机制,软件相对比较成熟,在此我就不一一推荐了。那么,既然有现成的 解决方案,那么我为什么要把它列为虚拟化软件的痛点呢?从我的使用经验来看,主要有以下原因:技术方面:此类软件一般不止监控文件读写、目录读写、重命名、拷贝,同时也会进行磁盘扫描,而这点,对于用于桌面云的增量磁盘来说是比较高的IOPS负载。对于一台12盘位的15K SAS机械硬盘存储设备,最多能扛住40到70台虚拟机同时扫描(数据来自某国产存储)。销售方面:标书中有时会提到“上述功能需来自同一厂商提供”,这就需要虚拟化厂商有一定实力,传统监控软件厂商才会与之合作为其定制,而这点对于现 在雨后春笋般的虚拟化厂商而言,正是痛处——目前国内各家虚拟化系统差异化严重,导致传统厂商为虚拟化定制的成本相对会比较高,而不愿意为国内中小厂商定 制了。目前这一状况随着国内市场的虚拟化推进正有所改善。痛点----->权限管理:政务中的权限管理包括:虚拟机控制权限管理、桌面软件安装权限管理、文件权限管理,对于开源虚拟化厂商而言,只有虚拟机控制权限自己可以控制,桌面 软件安装权限管理可以借助Windows AD来进行管理,当然需要一定开发量,而较细颗粒的文件权限管理则一样需要借助第三方。同文件监控一样,但是它一般不会进行后台文件扫描,但技术上要求是要和虚拟化紧耦合的状态,用某次客户交流的原话,“你最好界面里有一个控制台,我可以看到虚拟机里的Word文档,同时我也可以控制哪些人访问哪些文件”目前来说,这类权限管理软件可以配合集中/分布式存储软件(云存储),一般虚拟化厂商要在开源云存储的基础上进行大量修改才能达到国内政企客户的基本要求。目前国内有许多私有网盘厂商做的都不错,但是比较缺少它们和虚拟化厂商深度合作的案例。总结:政务私有桌面项目中,对桌面“虚拟化”的概念不是很有需求,除非有特别文件下发,即使下发后,客户还是倾向于按照传统的那一套路来。如果要在这个行业中产生影响,建议与传统软件厂商合作,一起发力。

教育

教育行业是目前国内大多数虚拟化厂商都在发力的市场,而这方面做的比较好的厂商有两类。一类是专注教育行业数十年乃至更长的传统软件厂商,他们拥有难以复制的经验,其私有云产品往往会弱化“虚拟化”概念,有强烈的“传统”色彩;还有就是专注教育行业的新厂商,他们的对教育行业的需求定位是从私有云的特性考虑,在解决问题的同时也能够将新理念传达至客户。学校对于虚拟桌面的需求近几年开始增长,教学机房、服务器机房、教师电脑等都有虚拟化产品的进入。而他们在虚拟化产品的采购上,关心桌面体验与服务器性能的同时,也比较在乎“成本”的问题。场景分析:
通用教学云模型 




用户桌面:学校中使用的桌面,一般可分为教师办公桌面和机房教学桌面。
教师桌面即普通办公桌面,主要用途即为老师提供日常办公软件,一般无特殊要求。对于机房教学桌面,有安装软件繁多、使用时间固定、并发量大等特点,比较考验虚拟化产品的综合素质。桌面安装软件除日常办公软件外,也包括各种文字、图形密集类教学软件,同时也可能会安装影音广播教学类软件。无特殊要求外,很少安装杀毒软件。系统管理:对于机房教学桌面,有安装软件繁多、使用时间固定、并发量大等特点,比较考验虚拟化产品的综合素质。桌面安装软件除日常办公软件外,也包括各种文字、图形密集类教学软件,同时也可能会安装影音广播教学类软件。无特殊要求外,很少安装杀毒软件。安全保障:教学环境中的安全要求一般比较低,除了常见的流量安全管理软件外,很少有桌面级监控软件。每个老师的桌面一般由管理员定期提醒查杀,主要维护工作还是由各个老师来做。痛点----->多媒体教学:那么对于进入教育行业的国内虚拟化厂商,可能都会遇到一个新旧交替环境中必须面对的问题——多媒体广播教学。传统教学机房使用多媒体广播卡或者广播教学软件来进行教学。多媒体广播卡即是在学生机、教师机上安装的硬件,广播时将教师端桌面转化后直接覆盖学生机的VGA信号,此时使用虚拟桌面并不影响广播体验,但是采用纯软件的多媒体教学系统时情况就有所不同了。这类软件进行视频广播时,默认会利用本地显卡的硬解能力,而一般虚拟化产品中并没有符合要求的模拟GPU硬件支持,所以会带来体验上的硬伤。不过比较喜人的是,这些厂商已经意识到这个问题,开始在其广播教学软件中加入了软解选项从而改善体验。还有就是在语音质量要求比较高的教学环境中,虚拟化厂商有时也会遭遇意外。语音质量的好坏,除了网络环境外,教学软件、虚拟化软件也有一定影响。在某次测试项目中,公司网络环境下的虚拟桌面语音很流畅、延迟极低,但是到客户机房后,就出现了杂音,声音小等问题。后来我们尝试优化协议、简化虚拟桌面网络拓扑,然后才取得令人满意的效果;多说一点,在呼叫中心(VoIP、传统PBX)这种语音传输质量要求极高的场景中,有时必须特定硬件配合才能完成虚拟桌面中语音的流畅。痛点----->3D教学:对于设计专业、工科专业来说,3D设计、3D模拟、3D建模都是很平常的科目,而这类软件采用学生机本地独显能很好地处理,但是到了虚拟化产品中就是整个开源虚拟化头疼的问题了。一般这种情况下,开源软件从技术上的处理方法可能不如闭源软件(Citrix、PCoIP、RDP RemoteFX)来的稳妥。由于它涉及到桌面协议、模拟器、GPU等相关知识,所以其开发难度较大,国内私有云厂商在未与GPU提供商合作的前提下很难在点有所突破。常见设计类软件比如Adobe Fireworks,在虚拟桌面中我们将“显示渲染”设置为“软件”,能够比较流畅的拖动、显示模型,但是此时会占用大量带宽,原生Spice协议此时甚至维持在20MBps,对于拥有几十台教学机的机房而言这点是不可接受的。另一种妥协的解决方式是采用RDP,带宽能降到10MBps,但是使用场景就被大大限制了。目前,国内这些3D教学类的项目,采用Citrix的多于VMWare,也有人使用Hyper-V,而极少有国内厂商提供KVM虚拟化的方案。我曾在KVM下的GPU虚拟化以及流媒体桌面协议有所尝试。总结:目前国内教育行业虚拟化前景广阔,但是伴随着现有kvm虚拟化的一些弱点以及人们面对虚拟桌面教学的担心,厂商在全面推广虚拟桌面的道路上走的比较艰辛。比较令人欣慰的是国内已经有大规模并发虚拟桌面的实例了,这点我相信会是一个很好的开端。

银行

目前国内教育行业虚拟化前景广阔,但是伴随着现有kvm虚拟化的一些弱点以及人们面对虚拟桌面教学的担心,厂商在全面推广虚拟桌面的道路上走的比较艰辛。比较令人欣慰的是国内已经有大规模并发虚拟桌面的实例了,这点我相信会是一个很好的开端。场景分析:



私有云在银行中目前在研发中心、服务集群、营业网点中都有应用,由于笔者经验有限,在此我们进行的讨论仅限于柜台虚拟桌面。

银行中现阶段核心业务由于历史原因,仍有相当部分的小型机在运行,x86服务器份额也在逐渐提高,并且慢慢取代小机成为核心业务承载。由于银行IT的特殊要求,他们使用虚拟化的步伐比较缓慢,一般在其研发机构或者网点柜台中使用较多。用户桌面:柜台桌面功能较为单一,从早期的DOS系统到现在的Win7桌面,柜员也只限于在上面查询、办理业务。所需软件除Office以为,也有一部分本行开发的软件与指定的杀毒软件。对于外设,常见的有高清摄像头、POS设备、读卡设备等。系统维护:柜台桌面一般会要求还原模式的桌面,大型网点部署在网点内部,小型网点部署在机房,由IT部门定期维护,系统一旦部署完成之后维护量较少。他们对于虚拟化的要求既是性能和功能只要满足,界面上复杂一些也能接受。痛点----->外设接入:那么问题来了,银行柜员桌面的外接设备繁多,除USB口以外也有串口、并口等设备。这些对于物理机来说都很轻松,但是到了虚拟机以后,就会出现这样那样的问题。读者于此可能会问,外接设备多对于技术上来说只是个协议转发的问题,有什么痛处呢?笔者总结有如下原因:设备接入到虚拟机以后,数据传输所需的额外带宽可能会对柜员机的其他业务产生影响,降低实时性,但是如果将可压缩数据进行无损压缩,对服务器和客户端又带来一定压力,需要较高性能的服务器与客户的才能保证实时性,势必又会导致虚拟化成本的上升。由于设备与接口繁多,一般的虚拟化厂商需要投入很大一部分物力与财力,甚至要开发专门的硬件设备来进行设备的重定向操作。很多设备尽管接口相同,但经过重定向以后仍然会出现不可识别的情况,需要厂商到现场进行测试甚至开发。正因为以上两点综合技术因素,现在众多虚拟化厂商谈到银行外设时仍谈虎色变。
痛点----->高实时性:影响柜台桌面实时性要求的主要因素有两个,一个是客户端到桌面的连接,另一个是桌面到业务系统的连接。一般由于虚拟桌面是由IT部门直接部署在离业务系统逻辑位置较近的地方,其网络质量较高,可以保证桌面到业务系统的延迟满足要求。但是客户端到桌面的网络是使用银行专有网络,网点到机房的带宽有限,并发高了以后网络拥堵所造成的延迟甚至丢包都会出现。总结:银行业相较于其他行业,其IT技术既先进又保守,而虚拟化产品除VMWare老牌厂商或者有行业背景的厂商外,他们的IT部门或多或少的有一定排斥心理。虽然银行客户交涉难度较大,但是如果成功以后就会树立很良好的产品及企业形象,所以,请努力。 查看全部


顾客就是上帝


传统的行业IT架构实现“云”化的过程多是基于现有业务系统采用为虚拟化,并辅之以资源池化等措施,渐渐构建为一个完整的私有云系统。由于各行业的业务系统差异较大,私有云落地过程中总会遇到这样那样的问题。作为一个技术人,将从私有云在典型行业的典型部门中落地的过程中,简述厂商在虚拟化方面很有可能遇到的痛点。


政务


政企中的桌面按职能划分包括办公、财务等,而这些正是桌面云的期望场景。加之目前国内政企在一些关键项目上非常乐意采用国内虚拟化产品,这也就给国内的IT厂商带来了机遇。
场景分析:
政企中的私有云,尤其是虚拟化部分近些年来一直在进行尝试性地推广。下面我以需求最直接的桌面云进行叙述。
zwyun.png

用户桌面:
面向办公的桌面,一般需求为Mircosoft Office、邮件处理等文字密集型软件;通信类软件一般为国内厂商开发的非广域网通信软件以及QQ;防病毒软件种类比较多,目前卡巴斯基、诺顿等占 多,360使用较少;影音类软件使用局限于网页flash,或者国内厂商定制的流媒体客户端。
对于财务桌面,需求除普通办公桌面外也有一些财务类软件,而这些软件对桌面负荷较普通办公桌面会高出一定量的资源消耗,同时也会有U-Key、指纹 仪等终端设备,所以对于这类桌面,我们一般进行特殊设置,比如将其固定到某台服务器上运行,并赋予一定优先级,保证资源优先分配。
在普通桌面与财务桌面以外,也有浮动桌面可供出差人员或者来访人员临时使用,此种桌面与一般办公桌面无异,但可能要求有严格的用户检查控制以及无状态模式要求,防止恶意使用导致损失。
系统维护:
政企中的网络管理人员一般为具有一定计算机水平的专业人士,并且他们在部门里推广办公桌面的时候起着很重要的作用。所以我们首先获得他们对产品的认可,解决他们在现有架构中遇到的管理困难。 不管在哪种场景中,管理人员对产品的认可,都是产品价值的体现之一 。
安全保障:
政务IT系统中的安全模块在系统的每个层次里都有体现,包括桌面、网络、交换设备、服务器、操作系统等,同时也可能会与其他基础设备连接,每个模块 相对独立又保持联系。一般在涉及安全的场景中,我们会采取服务端镜像加密和其他一系列的安全保障工作,兼顾性能和安全的同时保证桌面体验,这点在以后的章 节中会有所阐述。
虚拟化融合架构:
物理机与虚拟机同时提供服务的模式已经不是什么新东西了,早些年就已经有一大批使用虚拟服务器的政企客户,但涉及的产品基本以国外产品为主。随着国 产化的一系列强制措施和美国对华的服务器CPU的禁售,国产品牌才开始崭露头角。在一些服务器消耗量比较大的政企客户中,也渐渐地在周边业务系统上使用国 产虚拟化产品。我相信在未来几年内,国内虚拟化厂商会在政务云的服务器虚拟化中会占有很大比例,并且是不可替代的重要组成。
痛点----->文件监控:
谈政务云,多数标书中都会提到的一点就是文件监控。一般虚拟化厂商在这方面积累较少,使用fs-notify去开发有一定开发量,所以多数人会使用 第三方产品进行集成。国内常用的文件监控方法即使用Windows文件系统事件通知机制,软件相对比较成熟,在此我就不一一推荐了。那么,既然有现成的 解决方案,那么我为什么要把它列为虚拟化软件的痛点呢?
从我的使用经验来看,主要有以下原因:
技术方面:此类软件一般不止监控文件读写、目录读写、重命名、拷贝,同时也会进行磁盘扫描,而这点,对于用于桌面云的增量磁盘来说是比较高的IOPS负载。对于一台12盘位的15K SAS机械硬盘存储设备,最多能扛住40到70台虚拟机同时扫描(数据来自某国产存储)。
销售方面:标书中有时会提到“上述功能需来自同一厂商提供”,这就需要虚拟化厂商有一定实力,传统监控软件厂商才会与之合作为其定制,而这点对于现 在雨后春笋般的虚拟化厂商而言,正是痛处——目前国内各家虚拟化系统差异化严重,导致传统厂商为虚拟化定制的成本相对会比较高,而不愿意为国内中小厂商定 制了。目前这一状况随着国内市场的虚拟化推进正有所改善。
痛点----->权限管理:
政务中的权限管理包括:虚拟机控制权限管理、桌面软件安装权限管理、文件权限管理,对于开源虚拟化厂商而言,只有虚拟机控制权限自己可以控制,桌面 软件安装权限管理可以借助Windows AD来进行管理,当然需要一定开发量,而较细颗粒的文件权限管理则一样需要借助第三方。
同文件监控一样,但是它一般不会进行后台文件扫描,但技术上要求是要和虚拟化紧耦合的状态,用某次客户交流的原话,“你最好界面里有一个控制台,我可以看到虚拟机里的Word文档,同时我也可以控制哪些人访问哪些文件”
目前来说,这类权限管理软件可以配合集中/分布式存储软件(云存储),一般虚拟化厂商要在开源云存储的基础上进行大量修改才能达到国内政企客户的基本要求。目前国内有许多私有网盘厂商做的都不错,但是比较缺少它们和虚拟化厂商深度合作的案例。
总结:
政务私有桌面项目中,对桌面“虚拟化”的概念不是很有需求,除非有特别文件下发,即使下发后,客户还是倾向于按照传统的那一套路来。如果要在这个行业中产生影响,建议与传统软件厂商合作,一起发力。


教育


教育行业是目前国内大多数虚拟化厂商都在发力的市场,而这方面做的比较好的厂商有两类。一类是专注教育行业数十年乃至更长的传统软件厂商,他们拥有难以复制的经验,其私有云产品往往会弱化“虚拟化”概念,有强烈的“传统”色彩;还有就是专注教育行业的新厂商,他们的对教育行业的需求定位是从私有云的特性考虑,在解决问题的同时也能够将新理念传达至客户。
学校对于虚拟桌面的需求近几年开始增长,教学机房、服务器机房、教师电脑等都有虚拟化产品的进入。而他们在虚拟化产品的采购上,关心桌面体验与服务器性能的同时,也比较在乎“成本”的问题。
场景分析:
通用教学云模型 
sxyun.png

用户桌面:
学校中使用的桌面,一般可分为教师办公桌面和机房教学桌面。
教师桌面即普通办公桌面,主要用途即为老师提供日常办公软件,一般无特殊要求。
对于机房教学桌面,有安装软件繁多、使用时间固定、并发量大等特点,比较考验虚拟化产品的综合素质。桌面安装软件除日常办公软件外,也包括各种文字、图形密集类教学软件,同时也可能会安装影音广播教学类软件。无特殊要求外,很少安装杀毒软件。
系统管理:
对于机房教学桌面,有安装软件繁多、使用时间固定、并发量大等特点,比较考验虚拟化产品的综合素质。桌面安装软件除日常办公软件外,也包括各种文字、图形密集类教学软件,同时也可能会安装影音广播教学类软件。无特殊要求外,很少安装杀毒软件。
安全保障:
教学环境中的安全要求一般比较低,除了常见的流量安全管理软件外,很少有桌面级监控软件。每个老师的桌面一般由管理员定期提醒查杀,主要维护工作还是由各个老师来做。
痛点----->多媒体教学:
那么对于进入教育行业的国内虚拟化厂商,可能都会遇到一个新旧交替环境中必须面对的问题——多媒体广播教学。
传统教学机房使用多媒体广播卡或者广播教学软件来进行教学。多媒体广播卡即是在学生机、教师机上安装的硬件,广播时将教师端桌面转化后直接覆盖学生机的VGA信号,此时使用虚拟桌面并不影响广播体验,但是采用纯软件的多媒体教学系统时情况就有所不同了。这类软件进行视频广播时,默认会利用本地显卡的硬解能力,而一般虚拟化产品中并没有符合要求的模拟GPU硬件支持,所以会带来体验上的硬伤。不过比较喜人的是,这些厂商已经意识到这个问题,开始在其广播教学软件中加入了软解选项从而改善体验。
还有就是在语音质量要求比较高的教学环境中,虚拟化厂商有时也会遭遇意外。语音质量的好坏,除了网络环境外,教学软件、虚拟化软件也有一定影响。在某次测试项目中,公司网络环境下的虚拟桌面语音很流畅、延迟极低,但是到客户机房后,就出现了杂音,声音小等问题。后来我们尝试优化协议、简化虚拟桌面网络拓扑,然后才取得令人满意的效果;
多说一点,在呼叫中心(VoIP、传统PBX)这种语音传输质量要求极高的场景中,有时必须特定硬件配合才能完成虚拟桌面中语音的流畅。
痛点----->3D教学:
对于设计专业、工科专业来说,3D设计、3D模拟、3D建模都是很平常的科目,而这类软件采用学生机本地独显能很好地处理,但是到了虚拟化产品中就是整个开源虚拟化头疼的问题了。一般这种情况下,开源软件从技术上的处理方法可能不如闭源软件(Citrix、PCoIP、RDP RemoteFX)来的稳妥。
由于它涉及到桌面协议、模拟器、GPU等相关知识,所以其开发难度较大,国内私有云厂商在未与GPU提供商合作的前提下很难在点有所突破。
常见设计类软件比如Adobe Fireworks,在虚拟桌面中我们将“显示渲染”设置为“软件”,能够比较流畅的拖动、显示模型,但是此时会占用大量带宽,原生Spice协议此时甚至维持在20MBps,对于拥有几十台教学机的机房而言这点是不可接受的。另一种妥协的解决方式是采用RDP,带宽能降到10MBps,但是使用场景就被大大限制了。
目前,国内这些3D教学类的项目,采用Citrix的多于VMWare,也有人使用Hyper-V,而极少有国内厂商提供KVM虚拟化的方案。我曾在KVM下的GPU虚拟化以及流媒体桌面协议有所尝试。
总结:
目前国内教育行业虚拟化前景广阔,但是伴随着现有kvm虚拟化的一些弱点以及人们面对虚拟桌面教学的担心,厂商在全面推广虚拟桌面的道路上走的比较艰辛。比较令人欣慰的是国内已经有大规模并发虚拟桌面的实例了,这点我相信会是一个很好的开端。


银行


目前国内教育行业虚拟化前景广阔,但是伴随着现有kvm虚拟化的一些弱点以及人们面对虚拟桌面教学的担心,厂商在全面推广虚拟桌面的道路上走的比较艰辛。比较令人欣慰的是国内已经有大规模并发虚拟桌面的实例了,这点我相信会是一个很好的开端。
场景分析:
yyun.png
私有云在银行中目前在研发中心、服务集群、营业网点中都有应用,由于笔者经验有限,在此我们进行的讨论仅限于柜台虚拟桌面。

银行中现阶段核心业务由于历史原因,仍有相当部分的小型机在运行,x86服务器份额也在逐渐提高,并且慢慢取代小机成为核心业务承载。由于银行IT的特殊要求,他们使用虚拟化的步伐比较缓慢,一般在其研发机构或者网点柜台中使用较多。
用户桌面:
柜台桌面功能较为单一,从早期的DOS系统到现在的Win7桌面,柜员也只限于在上面查询、办理业务。所需软件除Office以为,也有一部分本行开发的软件与指定的杀毒软件。对于外设,常见的有高清摄像头、POS设备、读卡设备等。
系统维护:
柜台桌面一般会要求还原模式的桌面,大型网点部署在网点内部,小型网点部署在机房,由IT部门定期维护,系统一旦部署完成之后维护量较少。他们对于虚拟化的要求既是性能和功能只要满足,界面上复杂一些也能接受。
痛点----->外设接入:
那么问题来了,银行柜员桌面的外接设备繁多,除USB口以外也有串口、并口等设备。这些对于物理机来说都很轻松,但是到了虚拟机以后,就会出现这样那样的问题。
读者于此可能会问,外接设备多对于技术上来说只是个协议转发的问题,有什么痛处呢?笔者总结有如下原因:
设备接入到虚拟机以后,数据传输所需的额外带宽可能会对柜员机的其他业务产生影响,降低实时性,但是如果将可压缩数据进行无损压缩,对服务器和客户端又带来一定压力,需要较高性能的服务器与客户的才能保证实时性,势必又会导致虚拟化成本的上升。
由于设备与接口繁多,一般的虚拟化厂商需要投入很大一部分物力与财力,甚至要开发专门的硬件设备来进行设备的重定向操作。很多设备尽管接口相同,但经过重定向以后仍然会出现不可识别的情况,需要厂商到现场进行测试甚至开发。
正因为以上两点综合技术因素,现在众多虚拟化厂商谈到银行外设时仍谈虎色变。
痛点----->高实时性:
影响柜台桌面实时性要求的主要因素有两个,一个是客户端到桌面的连接,另一个是桌面到业务系统的连接。
一般由于虚拟桌面是由IT部门直接部署在离业务系统逻辑位置较近的地方,其网络质量较高,可以保证桌面到业务系统的延迟满足要求。但是客户端到桌面的网络是使用银行专有网络,网点到机房的带宽有限,并发高了以后网络拥堵所造成的延迟甚至丢包都会出现。
总结:
银行业相较于其他行业,其IT技术既先进又保守,而虚拟化产品除VMWare老牌厂商或者有行业背景的厂商外,他们的IT部门或多或少的有一定排斥心理。虽然银行客户交涉难度较大,但是如果成功以后就会树立很良好的产品及企业形象,所以,请努力。

浅谈软件架构设计

运维技术Rock 发表了文章 • 0 个评论 • 2331 次浏览 • 2016-02-26 00:14 • 来自相关话题

软件架构介绍

架构定义:软件架构不仅仅注重软件本身的结构和行为, 还注重其他特性:使用, 功能性, 性能, 弹性, 重用, 可理解性, 经济和技术的限制及权衡。软件架构的目标:
[]可延伸性(Extensible)。在新技术出现的时候,一个软件系统应当允许导入新技术,从而对现有系统进行功能和性能的扩展;[/][]可维护性(Maintainable)。软件系统的维护包括两方面:1、排除现有的错误;2、将新的软件需求反映到现有系统中去,一个易于维护的系统可以有效地降低技术支持的花费。[/][]客户体验(Customer Experience)。软件系统必须易于使用。[/][]市场时机(Time to Market)。软件用户[/]
 
软件逻辑架构:逻辑架构:软件系统中元件之间的关系,比如用户界面,数据库,外部系统接口,商业逻辑元件,等等软件系统的逻辑架构图:




 
软件物理架构:物理架构:软件元件是怎样放到硬件上的?软件系统的物理架构图





物联网架构的演变

单机(One Box)
简单web应用:
[]访问量小[/][]Apache/PHP/MySQL 在同一主机上[/][]瓶颈[/]
                 1、通常先出现在数据库,然后才是Apache/php
                 2、硬盘 I/O (Innodb) 或MyISAM锁等待




 
双机(Two Box)
[]访问量逐渐增大[/][]Apache/PHP在Server A;MySQL在Server B[/][]瓶颈[/]
                 1、硬盘 I/O (Innodb) 或MyISAM锁等待
                 2、网络I/O




 
多机 (Many Boxes with Replication)
[]访问量继续增大[/][]MySQL主从复制及读写分离 (master 负责IN/UP/DEL, slave负责 SELECT)[/][]SELECT, IN/UP/DEL可以在应用程序内指定访问不同服务器 (如使用不同的handle或Db Adapter)[/][]WEB Server可能需要使用负载均衡[/][]NoSQL/Cache/CDN[/]




 
系统分层:




Cache TierMemcached、Redis等广泛使用。



架构新问题
Mysql:
[]Slave Lag 每台Slave数据完全一样。有的忙,有的闲[/][]数据量越来越大,单表过大,查询效率太低;[/]
综合1.2 通常采用
[]memcached数据缓存 [/][]MySQL水平扩展(库表拆分)[/]
Web Server 负载过高 
[]提高PHP代码执行效率 Opcode Cache[/][]静态文件缓存  Squid/Varnish / CDN[/][]负载均衡[/]




 
新架构目标:
[]高可用[/][]高性能 [/][]可扩展 [/][]监控[/][]成本控制[/]

分布式系统架构

分布式系统概念What is a Distributed System?
“一个分布式系统是若干个独立的计算机的集合,但是对该系统的用户来说,系统就像一台计算机一样。”

两方面的含义:
[]硬件方面:各个计算机都是自治的 [/][]软件方面:用户将整个系统看作是一台计算机 [/]
 
 
分布式系统定义:一个分布式系统组织成中间件形式,中间件层分布在多台机器上。



分布式系统优点:




分布式操作系统特点:




 
网络操作系统(NOS)
网络操作系统的一般结构:





分布式系统中设计的关键问题:
透明性(对用户、程序)




灵活性




单内核基本上是目前的集中式操作系统,增加了网络功能和远程服务集合。 
微内核的四种基本服务:
        (1)进程间通信机制
        (2)少量内存管理功能
        (3)必要的低层进程管理和调度
        (4)低层输入/输出服务
可靠性




性能




可伸缩性(scalability)
避免:
[]集中式硬件[/][]集中式算法[/][]集中式的数据结构[/]
 




可扩展性
[]没有一台机器上存放着关于系统状态的全部信息[/][]机器只是基于本地信息做出决定[/][]一个机器出故障不会破坏算法[/][]不一定存在全局时钟。[/]
可扩展性示例:





总结

没有固定的架构,架构都是随着时间和业务的迁徙和变动而发生改变和重构的。所以架构不是一成不变的,也不是淘宝的架构就是万能的,适应你们业务的架构演变的架构就是最优架构。万变不离其宗,但是其底层技术实现和方法是可以借鉴采用大公司场景做法。 查看全部


软件架构介绍


架构定义:
软件架构不仅仅注重软件本身的结构和行为, 还注重其他特性:使用, 功能性, 性能, 弹性, 重用, 可理解性, 经济和技术的限制及权衡。
软件架构的目标:
    []可延伸性(Extensible)。在新技术出现的时候,一个软件系统应当允许导入新技术,从而对现有系统进行功能和性能的扩展;[/][]可维护性(Maintainable)。软件系统的维护包括两方面:1、排除现有的错误;2、将新的软件需求反映到现有系统中去,一个易于维护的系统可以有效地降低技术支持的花费。[/][]客户体验(Customer Experience)。软件系统必须易于使用。[/][]市场时机(Time to Market)。软件用户[/]

 
软件逻辑架构:
逻辑架构:软件系统中元件之间的关系,比如用户界面,数据库,外部系统接口,商业逻辑元件,等等
软件系统的逻辑架构图:
ceng.jpg

 
软件物理架构:
物理架构:软件元件是怎样放到硬件上的?
软件系统的物理架构图
wl.png


物联网架构的演变


单机(One Box)
简单web应用:
    []访问量小[/][]Apache/PHP/MySQL 在同一主机上[/][]瓶颈[/]

                 1、通常先出现在数据库,然后才是Apache/php
                 2、硬盘 I/O (Innodb) 或MyISAM锁等待
one.png

 
双机(Two Box)
    []访问量逐渐增大[/][]Apache/PHP在Server A;MySQL在Server B[/][]瓶颈[/]

                 1、硬盘 I/O (Innodb) 或MyISAM锁等待
                 2、网络I/O
two.png

 
多机 (Many Boxes with Replication)
    []访问量继续增大[/][]MySQL主从复制及读写分离 (master 负责IN/UP/DEL, slave负责 SELECT)[/][]SELECT, IN/UP/DEL可以在应用程序内指定访问不同服务器 (如使用不同的handle或Db Adapter)[/][]WEB Server可能需要使用负载均衡[/][]NoSQL/Cache/CDN[/]

many.png

 
系统分层:
fc.png

Cache Tier
Memcached、Redis等广泛使用。
cache.png

架构新问题
Mysql:
    []Slave Lag 每台Slave数据完全一样。有的忙,有的闲[/][]数据量越来越大,单表过大,查询效率太低;[/]

综合1.2 通常采用
    []memcached数据缓存 [/][]MySQL水平扩展(库表拆分)[/]

Web Server 负载过高 
    []提高PHP代码执行效率 Opcode Cache[/][]静态文件缓存  Squid/Varnish / CDN[/][]负载均衡[/]

fcache.png

 
新架构目标:
    []高可用[/][]高性能 [/][]可扩展 [/][]监控[/][]成本控制[/]


分布式系统架构


分布式系统概念
What is a Distributed System?
“一个分布式系统是若干个独立的计算机的集合,但是对该系统的用户来说,系统就像一台计算机一样。”

两方面的含义:
    []硬件方面:各个计算机都是自治的 [/][]软件方面:用户将整个系统看作是一台计算机 [/]

 
 
分布式系统定义:
一个分布式系统组织成中间件形式,中间件层分布在多台机器上。
fbs.png

分布式系统优点:
yd.png

分布式操作系统特点:
td.png

 
网络操作系统(NOS)
网络操作系统的一般结构:
netos.png


分布式系统中设计的关键问题:
透明性(对用户、程序)
tm.png

灵活性
lhx.png

单内核基本上是目前的集中式操作系统,增加了网络功能和远程服务集合。 
微内核的四种基本服务:
        (1)进程间通信机制
        (2)少量内存管理功能
        (3)必要的低层进程管理和调度
        (4)低层输入/输出服务
可靠性
kkx.png

性能
xn.png

可伸缩性(scalability)
避免:
    []集中式硬件[/][]集中式算法[/][]集中式的数据结构[/]

 
kssx.png

可扩展性
    []没有一台机器上存放着关于系统状态的全部信息[/][]机器只是基于本地信息做出决定[/][]一个机器出故障不会破坏算法[/][]不一定存在全局时钟。[/]

可扩展性示例:
sl.png


总结


没有固定的架构,架构都是随着时间和业务的迁徙和变动而发生改变和重构的。所以架构不是一成不变的,也不是淘宝的架构就是万能的,适应你们业务的架构演变的架构就是最优架构。万变不离其宗,但是其底层技术实现和方法是可以借鉴采用大公司场景做法。

大型网站系统架构演化之路

运维技术being 发表了文章 • 0 个评论 • 1033 次浏览 • 2016-01-10 16:26 • 来自相关话题

前言

一个成熟的大型网站(如淘宝、天猫、腾讯等)的系统架构并不是一开始设计时就具备完整的高性能、高可用、高伸缩等特性的,它是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式、技术架构、设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统架构是随着业务的扩展而逐步完善的,并不是一蹴而就;不同业务特征的系统,会有各自的侧重点,例如淘宝要解决海量的商品信息的搜索、下单、支付;例如腾讯要解决数亿用户的实时消息传输;百度它要处理海量的搜索请求;他们都有各自的业务特性,系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下,找出其中共用的技术,这些技术和手段广泛运用在大型网站系统的架构中,下面就通过介绍大型网站系统的演化过程,来认识这些技术和手段。

一、最开始的网站架构

最初的架构,应用程序、数据库、文件都部署在一台服务器上,如图:





二、应用、数据、文件分离

随着业务的扩展,一台服务器已经不能满足性能需求,故将应用程序、数据库、文件各自部署在独立的服务器上,并且根据服务器的用途配置不同的硬件,达到最佳的性能效果。





三、利用缓存改善网站性能

在硬件优化性能的同时,同时也通过软件进行性能优化,在大部分的网站系统中,都会利用缓存技术改善系统的性能,使用缓存主要源于热点数据的存在,大部分网站访问都遵循28原则(即80%的访问请求,最终落在20%的数据上),所以我们可以对热点数据进行缓存,减少这些数据的访问路径,提高用户体验。




缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理等,这个后面再讲。本地缓存,顾名思义是将数据缓存在应用服务器本地,可以存在内存中,也可以存在文件,OSCache就是常用的本地缓存组件。本地缓存的特点是速度快,但因为本地空间有限所以缓存数据量也有限。分布式缓存的特点是,可以缓存海量的数据,并且扩展非常容易,在门户类网站中常常被使用,速度按理没有本地缓存快,常用的分布式缓存是Memcached、Redis。

四、使用集群改善应用服务器性能

应用服务器作为网站的入口,会承担大量的请求,我们往往通过应用服务器集群来分担请求数。应用服务器前面部署负载均衡服务器调度用户请求,根据分发策略将请求分发到多个应用服务器节点。




常用的负载均衡技术硬件的有F5,价格比较贵,软件的有LVS、Nginx、HAProxy。LVS是四层负载均衡,根据目标地址和端口选择内部服务器,Nginx和HAProxy是七层负载均衡,可以根据报文内容选择内部服务器,因此LVS分发路径优于Nginx和HAProxy,性能要高些,而Nginx和HAProxy则更具配置性,如可以用来做动静分离(根据请求报文特征,选择静态资源服务器还是应用服务器)。

五、数据库读写分离和分库分表

随着用户量的增加,数据库成为最大的瓶颈,改善数据库性能常用的手段是进行读写分离以及分库分表,读写分离顾名思义就是将数据库分为读库和写库,通过主备功能实现数据同步。分库分表则分为水平切分和垂直切分,水平切分则是对一个数据库特大的表进行拆分,例如用户表。垂直切分则是根据业务的不同来切分,如用户业务、商品业务相关的表放在不同的数据库中。





六、使用CDN和反向代理提高网站性能

假如我们的服务器都部署在成都的机房,对于四川的用户来说访问是较快的,而对于北京的用户访问是较慢的,这是由于四川和北京分别属于电信和联通的不同发达地区,北京用户访问需要通过互联路由器经过较长的路径才能访问到成都的服务器,返回路径也一样,所以数据传输时间比较长。对于这种情况,常常使用CDN解决,CDN将数据内容缓存到运营商的机房,用户访问时先从最近的运营商获取数据,这样大大减少了网络访问的路径。比较专业的CDN运营商有蓝汛、网宿。




而反向代理,则是部署在网站的机房,当用户请求达到时首先访问反向代理服务器,反向代理服务器将缓存的数据返回给用户,如果没有缓存数据才会继续访问应用服务器获取,这样做减少了获取数据的成本。反向代理有Squid,Nginx。

七、使用分布式文件系统

用户一天天增加,业务量越来越大,产生的文件越来越多,单台的文件服务器已经不能满足需求,这时就需要分布式文件系统的支撑。常用的分布式文件系统有GFS、HDFS、TFS。





八、使用NoSql和搜索引擎

对于海量数据的查询和分析,我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb、hbase、redis,搜索引擎有lucene、solr、elasticsearch。





九、将应用服务器进行业务拆分

随着业务进一步扩展,应用程序变得非常臃肿,这时我们需要将应用程序进行业务拆分,如百度分为新闻、网页、图片等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者共享数据库来实现。





十、搭建分布式服务

这时我们发现各个业务应用都会使用到一些基本的业务服务,例如用户服务、订单服务、支付服务、安全服务,这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分部式服务框架搭建分布式服务。阿里的Dubbo是一个不错的选择。





总结

大型网站的架构是根据业务需求不断完善的,根据不同的业务特征会做特定的设计和考虑,本文只是讲述一个常规大型网站会涉及的一些技术和手段。

分享阅读整理原文:http://www.cnblogs.com/leefreeman/p/3993449.html
参考书籍:《大型网站技术架构》《海量运维运营规划》 查看全部


前言


一个成熟的大型网站(如淘宝、天猫、腾讯等)的系统架构并不是一开始设计时就具备完整的高性能、高可用、高伸缩等特性的,它是随着用户量的增加,业务功能的扩展逐渐演变完善的,在这个过程中,开发模式、技术架构、设计思想也发生了很大的变化,就连技术人员也从几个人发展到一个部门甚至一条产品线。所以成熟的系统架构是随着业务的扩展而逐步完善的,并不是一蹴而就;不同业务特征的系统,会有各自的侧重点,例如淘宝要解决海量的商品信息的搜索、下单、支付;例如腾讯要解决数亿用户的实时消息传输;百度它要处理海量的搜索请求;他们都有各自的业务特性,系统架构也有所不同。尽管如此我们也可以从这些不同的网站背景下,找出其中共用的技术,这些技术和手段广泛运用在大型网站系统的架构中,下面就通过介绍大型网站系统的演化过程,来认识这些技术和手段。


一、最开始的网站架构


最初的架构,应用程序、数据库、文件都部署在一台服务器上,如图:
website_arch1.png


二、应用、数据、文件分离


随着业务的扩展,一台服务器已经不能满足性能需求,故将应用程序、数据库、文件各自部署在独立的服务器上,并且根据服务器的用途配置不同的硬件,达到最佳的性能效果。
website_arch2.png


三、利用缓存改善网站性能


在硬件优化性能的同时,同时也通过软件进行性能优化,在大部分的网站系统中,都会利用缓存技术改善系统的性能,使用缓存主要源于热点数据的存在,大部分网站访问都遵循28原则(即80%的访问请求,最终落在20%的数据上),所以我们可以对热点数据进行缓存,减少这些数据的访问路径,提高用户体验。
website_arch3.png

缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理等,这个后面再讲。本地缓存,顾名思义是将数据缓存在应用服务器本地,可以存在内存中,也可以存在文件,OSCache就是常用的本地缓存组件。本地缓存的特点是速度快,但因为本地空间有限所以缓存数据量也有限。分布式缓存的特点是,可以缓存海量的数据,并且扩展非常容易,在门户类网站中常常被使用,速度按理没有本地缓存快,常用的分布式缓存是Memcached、Redis。


四、使用集群改善应用服务器性能


应用服务器作为网站的入口,会承担大量的请求,我们往往通过应用服务器集群来分担请求数。应用服务器前面部署负载均衡服务器调度用户请求,根据分发策略将请求分发到多个应用服务器节点。
website_arch4.png

常用的负载均衡技术硬件的有F5,价格比较贵,软件的有LVS、Nginx、HAProxy。LVS是四层负载均衡,根据目标地址和端口选择内部服务器,Nginx和HAProxy是七层负载均衡,可以根据报文内容选择内部服务器,因此LVS分发路径优于Nginx和HAProxy,性能要高些,而Nginx和HAProxy则更具配置性,如可以用来做动静分离(根据请求报文特征,选择静态资源服务器还是应用服务器)。


五、数据库读写分离和分库分表


随着用户量的增加,数据库成为最大的瓶颈,改善数据库性能常用的手段是进行读写分离以及分库分表,读写分离顾名思义就是将数据库分为读库和写库,通过主备功能实现数据同步。分库分表则分为水平切分和垂直切分,水平切分则是对一个数据库特大的表进行拆分,例如用户表。垂直切分则是根据业务的不同来切分,如用户业务、商品业务相关的表放在不同的数据库中。
website_arch5.png


六、使用CDN和反向代理提高网站性能


假如我们的服务器都部署在成都的机房,对于四川的用户来说访问是较快的,而对于北京的用户访问是较慢的,这是由于四川和北京分别属于电信和联通的不同发达地区,北京用户访问需要通过互联路由器经过较长的路径才能访问到成都的服务器,返回路径也一样,所以数据传输时间比较长。对于这种情况,常常使用CDN解决,CDN将数据内容缓存到运营商的机房,用户访问时先从最近的运营商获取数据,这样大大减少了网络访问的路径。比较专业的CDN运营商有蓝汛、网宿。
website_arch6.png

而反向代理,则是部署在网站的机房,当用户请求达到时首先访问反向代理服务器,反向代理服务器将缓存的数据返回给用户,如果没有缓存数据才会继续访问应用服务器获取,这样做减少了获取数据的成本。反向代理有Squid,Nginx。


七、使用分布式文件系统


用户一天天增加,业务量越来越大,产生的文件越来越多,单台的文件服务器已经不能满足需求,这时就需要分布式文件系统的支撑。常用的分布式文件系统有GFS、HDFS、TFS。
website_arch7.png


八、使用NoSql和搜索引擎


对于海量数据的查询和分析,我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb、hbase、redis,搜索引擎有lucene、solr、elasticsearch。
website_arch8.png


九、将应用服务器进行业务拆分


随着业务进一步扩展,应用程序变得非常臃肿,这时我们需要将应用程序进行业务拆分,如百度分为新闻、网页、图片等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者共享数据库来实现。
website_arch9.png


十、搭建分布式服务


这时我们发现各个业务应用都会使用到一些基本的业务服务,例如用户服务、订单服务、支付服务、安全服务,这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分部式服务框架搭建分布式服务。阿里的Dubbo是一个不错的选择。
website_arch10.png


总结


大型网站的架构是根据业务需求不断完善的,根据不同的业务特征会做特定的设计和考虑,本文只是讲述一个常规大型网站会涉及的一些技术和手段。


分享阅读整理原文:http://www.cnblogs.com/leefreeman/p/3993449.html
参考书籍:《大型网站技术架构》《海量运维运营规划》


互联网web架构和服务架构、存储解决方案、和云存储技术分享!