网上有很多关于pos机按键分离,数据库主从复制的知识，也有很多人为大家解答关于pos机按键分离的问题，今天pos机之家(www.poszjia.com)为大家整理了关于这方面的知识，让我们一起来看下吧!
本文目录一览：
1、pos机按键分离
pos机按键分离
随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天几十亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。通过数据切分来提高网站性能，横向扩展数据层已经成为架构研发人员首选的方式。
mysql主从复制原理
主要涉及三个线程：binlog 线程、I/O 线程和 SQL 线程。
binlog 线程 ：负责将主服务器上的数据更改写入二进制日志（Binary log）中。I/O 线程 ：负责从主服务器上读取二进制日志，并写入从服务器的中继日志（Relay log）。SQL 线程 ：负责读取中继日志，解析出主服务器已经执行的数据更改并在从服务器中重放（Replay）。这张图就很清晰表达出流程
1：主库db的更新事件(update、insert、delete)被写到binlog
2：从库发起连接，连接到主库3：此时主库创建一个binlog dump thread线程，把binlog的内容发送到从库
4：从库启动之后，创建一个I/O线程，读取主库传过来的binlog内容并写入到relay log
5：还会创建一个SQL线程，从relay log里面读取内容，从Exec_Master_Log_Pos位置开始执行读取到的更新事件，将更新内容写入到slave的db.
主从同步复制模式：
读写分离：
MYSQL读写分离的原理其实就是让Master数据库处理事务性增、删除、修改、更新操作（CREATE、INSERT、UPDATE、DELETE），而让Slave数据库处理SELECT操作，MYSQL读写分离前提是基于MYSQL主从复制，这样可以保证在Master上修改数据，Slave同步之后，WEB应用可以读取到Slave端的数据。
数据库分区：
分区并不是生成新的数据表，而是将表的数据均衡分摊到不同的硬盘，系统或是不同服务器存储介子中，实际上还是一张表。另外，分区可以做到将表的数据均衡到不同的地方，提高数据检索的效率，降低数据库的频繁IO压力值，分区的优点如下：
1、相对于单个文件系统或是硬盘，分区可以存储更多的数据；
2、数据管理比较方便，比如要清理或废弃某年的数据，就可以直接删除该日期的分区数据即可；
3、精准定位分区查询数据，不需要全表扫描查询，大大提高数据检索效率；
4、可跨多个分区磁盘查询，来提高查询的吞吐量；
5、在涉及聚合函数查询时，可以很容易进行数据的合并；
1、水平分区
这种形式分区是对表的行进行分区，通过这样的方式不同分组里面的物理列分割的数据集得以组合，从而进行个体分割（单分区）或集体分割（1个或多个分区）。所有在表中定义的列在每个数据集中都能找到，所以表的特性依然得以保持。
2、垂直分区
这种分区方式一般来说是通过对表的垂直划分来减少目标表的宽度，使某些特定的列被划分到特定的分区，每个分区都包含了其中的列所对应的行。
什么时候考虑使用分区？
一张表的查询速度已经慢到影响使用的时候。sql经过优化数据量大表中的数据是分段的对数据的操作往往只涉及一部分数据，而不是所有的数据分库分表：
分库分表的原因：
1、随着单库中的数据量越来越大，相应的，查询所需要的时间也越来越多，相当于数据的处理遇到了瓶颈2、单库发生意外的时候，需要修复的是所有的数据，而多库中的一个库发生意外的时候，只需要修复一个库（当然，也可以用物理分区的方式处理这种问题）
什么时候考虑使用分库？
单台DB的存储空间不够随着查询量的增加单台数据库服务器已经没办法支撑分库解决的问题：
其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。
垂直拆分
将系统中不存在关联关系或者需要join的表可以放在不同的数据库不同的服务器中。
按照业务垂直划分。比如：可以按照业务分为资金、会员、订单三个数据库。
需要解决的问题：跨数据库的事务、jion查询等问题。
水平拆分
例如，大部分的站点。数据都是和用户有关，那么可以根据用户，将数据按照用户水平拆分。
按照规则划分，一般水平分库是在垂直分库之后的。比如每天处理的订单数量是海量的，可以按照一定的规则水平划分。需要解决的问题：数据路由、组装。
什么时候考虑分表？
一张表的查询速度已经慢到影响使用的时候。sql经过优化数据量大当频繁插入或者联合查询时，速度变慢分表解决的问题
分表后，单表的并发能力提高了，磁盘I/O性能也提高了，写操作效率提高了
查询一次的时间短了数据分布在不同的文件，磁盘I/O性能提高读写锁影响的数据量变小插入数据库需要重新建立索引的数据减少垂直分表
水平分表
存储演变：
单库单表
单库单表是最常见的数据库设计，例如，有一张用户(user)表放在数据库db中，所有的用户都可以在db库中的user表中查到。
单库多表
随着用户数量的增加，user表的数据量会越来越大，当数据量达到一定程度的时候对user表的查询会渐渐的变慢，从而影响整个DB的性能。如果使用mysql, 还有一个更严重的问题是，当需要添加一列的时候，mysql会锁表，期间所有的读写操作只能等待。
可以通过某种方式将user进行水平的切分，产生两个表结构完全一样的user_0000,user_0001等表，user_0000 + user_0001 + …的数据刚好是一份完整的数据。
多库多表
随着数据量增加也许单台DB的存储空间不够，随着查询量的增加单台数据库服务器已经没办法支撑。这个时候可以再对数据库进行水平拆分。
数据库额外小知识：
MySQL 使用自增ID主键和UUID 作为主键的优劣比较详细过程（从百万到千万表记录测试）
（1）单实例或者单节点组：
经过500W、1000W的单机表测试，自增ID相对UUID来说，自增ID主键性能高于UUID，磁盘存储费用比UUID节省一半的钱。所以在单实例上或者单节点组上，使用自增ID作为首选主键。
（2）分布式架构场景：
20个节点组下的小型规模的分布式场景，为了快速实现部署，可以采用多花存储费用、牺牲部分性能而使用UUID主键快速部署；
20到200个节点组的中等规模的分布式场景，可以采用自增ID+步长的较快速方案。
200以上节点组的大数据下的分布式场景，可以借鉴类似twitter雪花算法构造的全局自增ID作为主键。
数据库分库分表，何时分？怎样分？
一. 数据切分关系型数据库本身比较容易成为系统瓶颈，单机存储容量、连接数、处理能力都有限。当单表的数据量达到1000W或100G以后，由于查询维 度较多，即使添加从库、优化索引，做很多操作时性能仍下降严重。此时就要考虑对其进行切分了，切分的目的就在于减少数据库的负担，缩短查询时间。
数据库分布式核心内容无非就是数据切分（Sharding），以及切分后对数据的定位、整合。数据切分就是将数据分散存储到多个数据库中，使得单一数据库中的数据量变小，通过扩充主机的数量缓解单一数据库的性能问题，从而达到提升数据库操作性能的目的。数据切分根据其切分类型，可以分为两种方式：垂直（纵向）切分和水平（横向）切分
什么是垂直（纵向）切分？垂直切分常见有垂直分库和垂直分表两种。
垂直分库就是根据业务耦合性，将关联度低的不同表存储在不同的数据库。做法与大系统拆分为多个小系统类似，按业务分类进行独立划分。与"微服务治理"的做法相似，每个微服务使用单独的一个数据库。如图：
垂直分表是基于数据库中的"列"进行，某个表字段较多，可以新建一张扩展表，将不经常用或字段长度较大的字段拆分出去到扩展表中。在字段很多的情况下（例 如一个大表有100多个字段），通过"大表拆小表"，更便于开发与维护，也能避免跨页问题，MySQL底层是通过数据页存储的，一条记录占用空间过大会导 致跨页，造成额外的性能开销。另外数据库以行为单位将数据加载到内存中，这样表中字段长度较短且访问频率较高，内存能加载更多的数据，命中率更高，减少了 磁盘IO，从而提升了数据库性能。
垂直切分的优点：
解决业务系统层面的耦合，业务清晰与微服务的治理类似，也能对不同业务的数据进行分级管理、维护、监控、扩展等高并发场景下，垂直切分一定程度的提升IO、数据库连接数、单机硬件资源的瓶颈缺点：
部分表无法join，只能通过接口聚合方式解决，提升了开发的复杂度分布式事务处理复杂依然存在单表数据量过大的问题（需要水平切分）什么是水平（横向）切分？当一个应用难以再细粒度的垂直切分，或切分后数据量行数巨大，存在单库读写、存储性能瓶颈，这时候就需要进行水平切分了。
水平切分分为库内分表和分库分表，是根据表内数据内在的逻辑关系，将同一个表按不同的条件分散到多个数据库或多个表中，每个表中只包含一部分数据，从而使得单个表的数据量变小，达到分布式的效果。如图所示：
库内分表只解决了单一表数据量过大的问题，但没有将表分布到不同机器的库上，因此对于减轻MySQL数据库的压力来说，帮助不是很大，大家还是竞争同一个物理机的CPU、内存、网络IO，最好通过分库分表来解决。
水平切分的优点：
不存在单库数据量过大、高并发的性能瓶颈，提升系统稳定性和负载能力应用端改造较小，不需要拆分业务模块缺点：
跨分片的事务一致性难以保证跨库的join关联查询性能较差数据多次扩展难度和维护量极大水平切分后同一张表会出现在多个数据库/表中，每个库/表的内容不同。
什么时候考虑切分1、能不切分尽量不要切分
并不是所有表都需要进行切分，主要还是看数据的增长速度。切分后会在某种程度上提升业务的复杂度，数据库除了承载数据的存储和查询外，协助业务更好的实现需求也是其重要工作之一。
不到万不得已不用轻易使用分库分表这个大招，避免"过度设计"和"过早优化"。分库分表之前，不要为分而分，先尽力去做力所能及的事情，例如：升级硬件、升级网络、读写分离、索引优化等等。当数据量达到单表的瓶颈时候，再考虑分库分表。
2、数据量过大，正常运维影响业务访问
这里说的运维，指：
1）对数据库备份，如果单表太大，备份时需要大量的磁盘IO和网络IO。例如1T的数据，网络传输占50MB时候，需要20000秒才能传输完毕，整个过程的风险都是比较高的
2）对一个很大的表进行DDL修改时，MySQL会锁住全表，这个时间会很长，这段时间业务不能访问此表，影响很大。如果使用pt- online-schema-change，使用过程中会创建触发器和影子表，也需要很长的时间。在此操作过程中，都算为风险时间。将数据表拆分，总量减 少，有助于降低这个风险。
3）大表会经常访问与更新，就更有可能出现锁等待。将数据切分，用空间换时间，变相降低访问压力
3、随着业务发展，需要对某些字段垂直拆分
4、数据量快速增长
随着业务的快速发展，单表中的数据量会持续增长，当性能接近瓶颈时，就需要考虑水平切分，做分库分表了。此时一定要选择合适的切分规则，提前预估好数据容量
5、安全性和可用性
鸡蛋不要放在一个篮子里。在业务层面上垂直切分，将不相关的业务的数据库分隔，因为每个业务的数据量、访问量都不同，不能因为一个业务把数 据库搞挂而牵连到其他业务。利用水平切分，当一个数据库出现问题时，不会影响到100%的用户，每个库只承担业务的一部分数据，这样整体的可用性就能提 高。
案例分析1、用户中心业务场景
用户中心是一个非常常见的业务，主要提供用户注册、登录、查询/修改等功能，其核心表为：
任何脱离业务的架构设计都是耍流氓，在进行分库分表前，需要对业务场景需求进行梳理：
用户侧：前台访问，访问量较大，需要保证高可用和高一致性。主要有两类需求：用户登录：通过login_name/phone/email查询用户信息，1%请求属于这种类型用户信息查询：登录之后，通过uid来查询用户信息，99%请求属这种类型运营侧：后台访问，支持运营需求，按照年龄、性别、登陆时间、注册时间等进行分页的查询。是内部系统，访问量较低，对可用性、一致性的要求不高。2、水平切分方法
当数据量越来越大时，需要对数据库进行水平切分，上文描述的切分方法有"根据数值范围"和"根据数值取模"。
"根据数值范围"：以主键uid为划分依据，按uid的范围将数据水平切分到多个数据库上。例如：user-db1存储uid范围为0~1000w的数据，user-db2存储uid范围为1000w~2000wuid数据。
优点是：扩容简单，如果容量不够，只要增加新db即可。不足是：请求量不均匀，一般新注册的用户活跃度会比较高，所以新的user-db2会比user-db1负载高，导致服务器利用率不平衡"根据数值取模"：也是以主键uid为划分依据，按uid取模的值将数据水平切分到多个数据库上。例如：user-db1存储uid取模得1的数据，user-db2存储uid取模得0的uid数据。
优点是：数据量和请求量分布均均匀不足是：扩容麻烦，当容量不够时，新增加db，需要rehash。需要考虑对数据进行平滑的迁移。3、非uid的查询方法
水平切分后，对于按uid查询的需求能很好的满足，可以直接路由到具体数据库。而按非uid的查询，例如login_name，就不知道具体该访问哪个库了，此时需要遍历所有库，性能会降低很多。
对于用户侧，可以采用"建立非uid属性到uid的映射关系"的方案；对于运营侧，可以采用"前台与后台分离"的方案。
3.1、建立非uid属性到uid的映射关系
1）映射关系
例如：login_name不能直接定位到数据库，可以建立login_name→uid的映射关系，用索引表或缓存来存储。当访问login_name时，先通过映射表查询出login_name对应的uid，再通过uid定位到具体的库。
映射表只有两列，可以承载很多数据，当数据量过大时，也可以对映射表再做水平切分。这类kv格式的索引结构，可以很好的使用cache来优化查询性能，而且映射关系不会频繁变更，缓存命中率会很高。
3.2、前台与后台分离
对于用户侧，主要需求是以单行查询为主，需要建立login_name/phone/email到uid的映射关系，可以解决这些字段的查询问题。
而对于运营侧，很多批量分页且条件多样的查询，这类查询计算量大，返回数据量大，对数据库的性能消耗较高。此时，如果和用户侧公用同一批服务或数据库，可能因为后台的少量请求，占用大量数据库资源，而导致用户侧访问性能降低或超时。
这类业务最好采用"前台与后台分离"的方案，运营侧后台业务抽取独立的service和db，解决和前台业务系统的耦合。由于运营侧对可用 性、一致性的要求不高，可以不访问实时库，而是通过binlog异步同步数据到运营库进行访问。在数据量很大的情况下，还可以使用ES搜索引擎或Hive 来满足后台复杂的查询方式。
常用的支持分库分表中间件：sharding-jdbc（当当）TSharding（蘑菇街）Atlas（奇虎360）Cobar（阿里巴巴）MyCAT（基于Cobar）Oceanus（58同城）Vitess（谷歌）以上就是关于pos机按键分离,数据库主从复制的知识，后面我们会继续为大家整理关于pos机按键分离的知识，希望能够帮助到大家！
