一、QPS/TPSQPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准一、QPS/TPSQPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够相应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。Tps即每秒处理事务数，包括了1）用户请求服务器2）服务器自己的内部处理3）服务器返回给用户这三个过程，每秒能够完成N个这三个过程，Tps也就是N；Qps基本类似于Tps，但是不同的是，对于一个页面的一次访问，形成一个Tps；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“Qps”之中。例如：访问一个页面会请求服务器3次，一次放，产生一个“T”，产生3个“Q” 二、系统吞吐量一个系统的吞度量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个reqeust 对CPU消耗越高，外部系统接口、IO影响速度越慢，系统吞吐能力越低，反之越高。系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间        QPS（TPS）：每秒钟request/事务 数量        并发数： 系统同时处理的request/事务数        响应时间：  一般取平均响应时间理解了上面三个要素的意义之后，就能推算出它们之间的关系：QPS（TPS）= 并发数/平均响应时间    或者   并发数 = QPS*平均响应时间

分布式系统架构_分布式事物_分布式系统原理<h2>引言</h2>     随着大数据时代的到来。大多数之前业务系统已经无法承受大数据带来的冲击。各个大公司小公司都在考虑如何优化自己的业务系统。提高业务能力减少成本支出。随之就引出了 <strong>分布式系统</strong>。 <h2>一.为什么要进行<strong>分布式系统架构</strong>？</h2> <p>  大多数的开发者大多数的系统可能从来没接触过分布式系统，也根本没必要进行分布式系统架构，为什么？因为在访问量或者QPS没有达到单台机器的性能瓶颈的时候，根本没必要进行分布式架构。那如果业务量上来了，一般会怎么解决呢？</p> <p>    首先考虑的就是机器升级。机器配置的垂直扩展，首先要找到当前性能的瓶颈点，是CPU，是内存，是硬盘，还是带宽。砸钱加CPU，砸钱换SSD硬盘，砸钱换1T内存，这通常是解决问题最直接也最高效的方法。带宽不够？加带宽，1G不够用100G。CPU 8核不够？搞32核96核。这是绝大多数公司能思考到的第一个方案，也是最高效最快最安全的方法，立竿见影。</p> <p>    其次就是系统拆分，将所提供服务的主流程以及支线流程梳理出来，按照流程进行系统拆分。如同一棵树，核心业务作为主干流程，其他系统按照需要进行拆分，如同树的开枝散叶。所采取的方式有这么一些，按前后端进行拆分，按照领域拆分，按团队拆分，当然通常来说这些拆分基本都要跟着组织架构走。</p> <p>    再不行就进行技术升级，更换更加高效或者场景适合的技术。比如从 Oracle 更换到HBase。从A数据库连接池更换到B数据库连接池。技术的变革对于业务量的支持也是非常巨大的，同一台机器不同的技术，效能发挥的程度可以说有天壤之别。</p> <p>    最后的最后手段才会考虑分布式架构，实在是砸不出这么多钱了，实在是没办法了。因为分布式架构肯定会带来非常多非常多的一致性问题，原本只需要访问一台机器，现在需要访问N台，那么这N台机器的一致性怎么保证，以前撑死搞个主从备份就算完了，定时同步一下数据就好，现在N台设备的数据怎么管理，甚至这个集群本身怎么管理，都会成为一个致命的问题。</p> <p>    所以只有等业务量到达一定程度了，单台机器扛不住了，才会开始堆钱升级机器，系统拆分，换技术，继续堆钱升级机器，系统拆分...周而复始，发现成本太高或者技术已经到达上线了。最后没办法，就选择分布式架构了。</p> <p>但是分布式架构的优势也是明显的，用一群低廉的设备，来提供一个高性能高吞吐量的稳定的系统，下面开始说说常见的分布式集群的架构。</p> <h2>二.分布式系统架构的几种模式</h2> <h3>2.1纯负载均衡模式</h3>     在集群前面，前置一个流量分发的组件进行流量分发，整个集群的机器提供无差别的服务，这在常见的 web 服务器中是最最常见的。目前比较主流的方式就是整个集群机器上云，根据实时的调用量进行云服务器弹性伸缩。常见的负载均衡有硬件层面的 F5、软件层面的 nginx 等。<br /> <img alt="传统负载均衡" class="img-thumbnail" src="/assist/images/blog/c9ccf03ca8b54ac4852bbe8f1abf10b7.png" /> <h3>2.2<strong>领导选举型</strong></h3> 整个集群的消息都会转发到集群的领导这里，是一种 master-slavers，区别只是这个 master 是被临时选举出来的，一旦 master 宕机，集群会立刻选举出一个新的领导，继续对外提供服务。使用领导选举型架构的典型的应用有 ElasticSearch，zookeeper。<br /> <img alt="领导选举" class="img-thumbnail" src="/assist/images/blog/06857af58c4f4b31a75e5b4ac28f19ed.jpg" /> <h3><strong>2.3区块链型</strong><br /> 整个集群的每一个节点都可以进行记录，但是记录的内容要得到整个集群 N 个机器的认可才是合法的。典型的应用有 Bit Coin，以及 Hyperledger。</h3> <img alt="整个集群的消息都会转发到集群的领导这里，是一种 master-slavers，区别只是这个 master 是被临时选举出来的，一旦 master 宕机，集群会立刻选举出一个新的领导，继续对外提供服务。使用领导选举型架构的典型的应用有 ElasticSearch，zookeeper。" class="img-thumbnail" src="/assist/images/blog/78cd41be88fa409c9c11e77c5ef193ff.jpg" /> <h3>2.4<strong>master-slaver型</strong></h3> 整个集群以某台 master 为中枢，进行集群的调度。交互是这样，一般会把所有的管理类型的数据放到 master 上，而把具体的数据放到 slaver 上，实际进行调用的时候，client 先调用 master 获取数据所存放的 server 的 信息，再自行跟 slave 进行交互。典型的系统有 Hadoop。集群，HBase 集群，Redis 集群等。<br /> <img alt="整个集群以某台 master 为中枢，进行集群的调度。交互是这样，一般会把所有的管理类型的数据放到 master 上，而把具体的数据放到 slaver 上，实际进行调用的时候，client 先调用 master 获取数据所存放的 server 的 信息，再自行跟 slave 进行交互。典型的系统有 Hadoop。集群，HBase 集群，Redis 集群等。" class="img-thumbnail" src="/assist/images/blog/68bb6e12564d491da16f3569088b7896.jpg" /> <h3>2.5<strong>规则型一致性Hash</strong></h3> 这种架构类型一般出现在数据库分库分表的设计中。按照规则进行分库分表，在查询之前使用规则引擎进行库和表的确认，再对具体的应用进行访问。为什么要用一致性 Hash ？其实用什么都可以，只是对于这类应用来说一致性 Hash 比较常见而已。<br /> <img alt="这种架构类型一般出现在数据库分库分表的设计中。按照规则进行分库分表，在查询之前使用规则引擎进行库和表的确认，再对具体的应用进行访问。为什么要用一致性 Hash ？其实用什么都可以，只是对于这类应用来说一致性 Hash 比较常见而已。" class="img-thumbnail" src="/assist/images/blog/2735e320027f4f91bbd9319fda6f5b93.jpg" /><br />  

redis 命令查看使用情况redis info命令详解,redis查看内存使用情况。redis info命令的详细解释<p>通过redis-cli连接到redis服务</p> <pre> <code class="language-html">redis-cli -h 192.168.1.3 -p 6300 192.168.1.3:6300> 192.168.1.3:6300> auth pass 192.168.1.3:6300> info all</code></pre> <pre> <code class="language-bash"># Server(服务器信息) redis_version:3.0.0                              #redis服务器版本 redis_git_sha1:00000000                  #Git SHA1 redis_git_dirty:0                                    #Git dirty flag redis_build_id:6c2c390b97607ff0    #redis build id redis_mode:cluster                              #运行模式，单机或者集群 os:Linux 2.6.32-358.2.1.el6.x86_64 x86_64 #redis服务器的宿主操作系统 arch_bits:64                                         #架构(32或64位) multiplexing_api:epoll                        #redis所使用的事件处理机制 gcc_version:4.4.7                                #编译redis时所使用的gcc版本 process_id:12099                               #redis服务器进程的pid run_id:63bcd0e57adb695ff0bf873cf42d403ddbac1565  #redis服务器的随机标识符(用于sentinel和集群) tcp_port:9021                                #redis服务器监听端口 uptime_in_seconds:26157730   #redis服务器启动总时间，单位是秒 uptime_in_days:302                    #redis服务器启动总时间，单位是天 hz:10                                #redis内部调度（进行关闭timeout的客户端，删除过期key等等）频率，程序规定serverCron每秒运行10次。 lru_clock:14359959      #自增的时钟，用于LRU管理,该时钟100ms(hz=10,因此每1000ms/10=100ms执行一次定时任务)更新一次。 config_file:/redis_cluster/etc/9021.conf  #配置文件路径 # Clients(已连接客户端信息) connected_clients:1081       #已连接客户端的数量(不包括通过slave连接的客户端) client_longest_output_list:0 #当前连接的客户端当中，最长的输出列表，用client list命令观察omem字段最大值 client_biggest_input_buf:0   #当前连接的客户端当中，最大输入缓存，用client list命令观察qbuf和qbuf-free两个字段最大值 blocked_clients:0                   #正在等待阻塞命令(BLPOP、BRPOP、BRPOPLPUSH)的客户端的数量 # Memory(内存信息) used_memory:327494024                 #由redis分配器分配的内存总量，以字节为单位 used_memory_human:312.32M       #以人类可读的格式返回redis分配的内存总量 used_memory_rss:587247616         #从操作系统的角度，返回redis已分配的内存总量(俗称常驻集大小)。这个值和top命令的输出一致 used_memory_peak:1866541112    #redis的内存消耗峰值(以字节为单位)  used_memory_peak_human:1.74G #以人类可读的格式返回redis的内存消耗峰值 used_memory_lua:35840                   #lua引擎所使用的内存大小(以字节为单位) mem_fragmentation_ratio:1.79          #used_memory_rss和used_memory之间的比率，小于1表示使用了swap，大于1表示碎片比较多 mem_allocator:jemalloc-3.6.0            #在编译时指定的redis所使用的内存分配器。可以是libc、jemalloc或者tcmalloc # Persistence(rdb和aof的持久化相关信息) loading:0                                                    #服务器是否正在载入持久化文件 rdb_changes_since_last_save:28900855 #离最近一次成功生成rdb文件，写入命令的个数，即有多少个写入命令没有持久化 rdb_bgsave_in_progress:0                  #服务器是否正在创建rdb文件 rdb_last_save_time:1482358115        #离最近一次成功创建rdb文件的时间戳。当前时间戳 - rdb_last_save_time=多少秒未成功生成rdb文件 rdb_last_bgsave_status:ok                   #最近一次rdb持久化是否成功 rdb_last_bgsave_time_sec:2                #最近一次成功生成rdb文件耗时秒数 rdb_current_bgsave_time_sec:-1        #如果服务器正在创建rdb文件，那么这个域记录的就是当前的创建操作已经耗费的秒数 aof_enabled:1                                          #是否开启了aof aof_rewrite_in_progress:0                     #标识aof的rewrite操作是否在进行中 aof_rewrite_scheduled:0               #rewrite任务计划，当客户端发送bgrewriteaof指令，如果当前rewrite子进程正在执行，那么将客户端请求的bgrewriteaof变为计划任务，待aof子进程结束后执行rewrite  aof_last_rewrite_time_sec:-1            #最近一次aof rewrite耗费的时长 aof_current_rewrite_time_sec:-1      #如果rewrite操作正在进行，则记录所使用的时间，单位秒 aof_last_bgrewrite_status:ok             #上次bgrewriteaof操作的状态 aof_last_write_status:ok                     #上次aof写入状态 aof_current_size:4201740                 #aof当前尺寸 aof_base_size:4201687                    #服务器启动时或者aof重写最近一次执行之后aof文件的大小 aof_pending_rewrite:0                       #是否有aof重写操作在等待rdb文件创建完毕之后执行? aof_buffer_length:0                             #aof buffer的大小 aof_rewrite_buffer_length:0              #aof rewrite buffer的大小 aof_pending_bio_fsync:0                  #后台I/O队列里面，等待执行的fsync调用数量 aof_delayed_fsync:0                          #被延迟的fsync调用数量 # Stats(一般统计信息) total_connections_received:209561105 #新创建连接个数,如果新创建连接过多，过度地创建和销毁连接对性能有影响，说明短连接严重或连接池使用有问题，需调研代码的连接设置 total_commands_processed:2220123478  #redis处理的命令数 instantaneous_ops_per_sec:279                  #redis当前的qps，redis内部较实时的每秒执行的命令数 total_net_input_bytes:118515678789          #redis网络入口流量字节数 total_net_output_bytes:236361651271       #redis网络出口流量字节数 instantaneous_input_kbps:13.56                  #redis网络入口kps instantaneous_output_kbps:31.33               #redis网络出口kps rejected_connections:0                                   #拒绝的连接个数，redis连接个数达到maxclients限制，拒绝新连接的个数 sync_full:1                                                          #主从完全同步成功次数 sync_partial_ok:0                                             #主从部分同步成功次数 sync_partial_err:0                                            #主从部分同步失败次数 expired_keys:15598177                                #运行以来过期的key的数量 evicted_keys:0                                                 #运行以来剔除(超过了maxmemory后)的key的数量 keyspace_hits:1122202228                          #命中次数 keyspace_misses:577781396                     #没命中次数 pubsub_channels:0                                       #当前使用中的频道数量 pubsub_patterns:0                                         #当前使用的模式的数量 latest_fork_usec:15679                                 #最近一次fork操作阻塞redis进程的耗时数，单位微秒 migrate_cached_sockets:0                          # # Replication(主从信息，master上显示的信息) role:master                               #实例的角色，是master or slave connected_slaves:1              #连接的slave实例个数 slave0:ip=192.168.64.104,port=9021,state=online,offset=6713173004,lag=0 #lag从库多少秒未向主库发送REPLCONF命令 master_repl_offset:6713173145  #主从同步偏移量,此值如果和上面的offset相同说明主从一致没延迟 repl_backlog_active:1                   #复制积压缓冲区是否开启 repl_backlog_size:134217728    #复制积压缓冲大小 repl_backlog_first_byte_offset:6578955418  #复制缓冲区里偏移量的大小 repl_backlog_histlen:134217728   #此值等于 master_repl_offset - repl_backlog_first_byte_offset,该值不会超过repl_backlog_size的大小 # Replication(主从信息，slave上显示的信息) role:slave                                        #实例的角色，是master or slave master_host:192.168.64.102       #此节点对应的master的ip master_port:9021                          #此节点对应的master的port master_link_status:up                   #slave端可查看它与master之间同步状态,当复制断开后表示down master_last_io_seconds_ago:0  #主库多少秒未发送数据到从库? master_sync_in_progress:0        #从服务器是否在与主服务器进行同步 slave_repl_offset:6713173818   #slave复制偏移量 slave_priority:100                          #slave优先级 slave_read_only:1                         #从库是否设置只读 connected_slaves:0                      #连接的slave实例个数 master_repl_offset:0          repl_backlog_active:0                  #复制积压缓冲区是否开启 repl_backlog_size:134217728   #复制积压缓冲大小 repl_backlog_first_byte_offset:0 #复制缓冲区里偏移量的大小 repl_backlog_histlen:0           #此值等于 master_repl_offset - repl_backlog_first_byte_offset,该值不会超过repl_backlog_size的大小 # CPU(CPU计算量统计信息) used_cpu_sys:96894.66             #将所有redis主进程在核心态所占用的CPU时求和累计起来 used_cpu_user:87397.39           #将所有redis主进程在用户态所占用的CPU时求和累计起来 used_cpu_sys_children:6.37     #将后台进程在核心态所占用的CPU时求和累计起来 used_cpu_user_children:52.83 #将后台进程在用户态所占用的CPU时求和累计起来 # Commandstats(各种不同类型的命令的执行统计信息) cmdstat_get:calls=1664657469,usec=8266063320,usec_per_call=4.97   #call每个命令执行次数,usec总共消耗的CPU时长(单位微秒),平均每次消耗的CPU时长(单位微秒) # Cluster(集群相关信息) cluster_enabled:1   #实例是否启用集群模式 # Keyspace(数据库相关的统计信息) db0:keys=194690,expires=191702,avg_ttl=3607772262 #db0的key的数量,以及带有生存期的key的数,平均存活时间</code></pre>