并发和tps的关系,并发和Tps的关系

1. tps的中文全称是什么？
2. 高并发场景下，如何实现数据库主从同步？
3. Kafka，Mq和Redis作为消息队列使用时的差异有哪些？

tps的中文全称是什么？

TPS全称是：Transaction Per Second，意思是指每秒事务数。TPS是衡量系统性能的一个非常重要的指标。

在做性能测试的时候，传统方式都是用并发数来衡量系统的性能，一般适用于一些网页站点的首页、H5页面的压测。这是站在客户端的视角。而TPS则直接衡量系统的吞吐能力，应用场景主要是一些动态的接口API，例如登录、提交订单等等。这是站在服务端视角的。

高并发场景下，如何实现数据库主从同步？

常用方案是数据库读写分离技术。不过既然题主提到了高并发场景，我就来告诉你，event sourcing——事件溯源，eventuate架构就提供，和CQRS——应用层写读分离。再结合kafka这类的消息中间件，或是阿里的c***数据库日志同步解决方案，可以搭建一个完美的高并发事务与实时在线响应系统，当然这种读写分离系统的事务是最终一致性的，题主可自行百度我说的各项技术。如果题主和各位看官觉得有价值，就请点个赞吧

数据主从同步的由来

互联网的很多业务，特别是在高并发的场景下，基本都是读远远大于写，如果数据库读和写的压力都同在一台主机上，这显然不太合理。

于是，把一台数据库主机分为单独的一台写主库（主要负责写操作），而把读的数据库压力分配给读的从库，而且读从库可以变为多台，这就是读写分离的典型场景如下：

为了进一步的降低数据库端的压力(高并发的瓶颈)，这个时候也会在业务层部署分布式缓存集群(redis、memcached)等，把读的压力转移给应用服务器端，其实与数据主从的设计是遵循同一个原则，降低后端数据库的压力。

问题：

读写分离提高了***的利用效率的同时也引出了一个问题，就是由于延时（网络传输，操作）而引起的数据库主从不一致的问题，以下会详细谈相关的数据一致性解决方案。

数据同步一致性解决方案

1.半同步***

办法就是等主从同步完成之后，等主库上的写请求再返回，这就是常说的“半同步***"。

实现方案

mysql的半同步***方案，下面我以mysql为例介绍。

MySQL半同步***

MySQL的Replication默认是一个异步***的过程，从MySQL5.5开始，MySQL以插件的形式支持半同步***，我先谈下异步***，这样可以更好的理解半同步***。

1）异步***

MySQL默认的***是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从库上。

2）半同步***

对于异步***和全同步***之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步***，半同步***提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步***最好在低延时的网络中使用。

半同步***原理：

事务在主库写完binlog后需要从库返回一个已接受，才放回给客户端

mysql5.5版本以后，以插件的形式存在，需要单独安装

确保事务提交后binlog至少传输到一个从库

不保证从库应用完成这个事务的binlog

性能有一定的降低

网络异常或从库宕机，卡主库，直到超时或从库恢复

该方案优点：

利用数据库原生功能，比较简单

该方案缺点：

主库的写请求时延会增长，吞吐量会降低

2.数据库中间件

流程：

1）所有的读写都走数据库中间件，通常情况下，写请求路由到主库，读请求路由到从库

2）记录所有路由到写库的key，在主从同步时间窗口内（***设是500ms），如果有读请求访问中间件，此时有可能从库还是旧数据，就把这个key上的读请求路由到主库。

3）在主从同步时间过完后，对应key的读请求继续路由到从库。

相关的中间件有：

1）c***:是阿里巴巴旗下的一款开源项目，纯Java开发,基于数据库增量日志解析，提供增量数据订阅&消费，目前主要支持了MySQL。

2）otter：也是阿里开源的一个分布式数据库同步系统，尤其是在跨机房数据库同步方面，有很强大的功能。它是基于数据库增量日志解析，实时将数据同步到本机房或跨机房的mysql/oracle数据库。

两者的区别在于：

otter目前嵌入式依赖c***，部署为同一个jvm，目前设计为不产生Relay Log。

otter目前允许自定义同步逻辑，解决各类需求。

该方案优点

能保证绝对一致

该方案缺点：

数据库中间件的成本较高

3.缓存记录写key法

写流程：

1）如果key要发生写操作，记录在cache里，并设置“经验主从同步时间”的cache超时时间，例如500ms

2）然后修改主数据库

读流程：

1）先到缓存里查看，对应key有没有相关数据

2）有相关数据，说明缓存命中，这个key刚发生过写操作，此时需要将请求路由到主库读最新的数据。

3）如果缓存没有命中，说明这个key上近期没有发生过写操作，此时将请求路由到从库，继续读写分离。

该方案优点：

相对数据库中间件，成本较低

该方案缺点：

为了保证“一致性”，引入了一个cache组件，并且读写数据库时都多了缓存操作。

Kafka，Mq和Redis作为消息队列使用时的差异有哪些？

补充一下使用场景：

Redis 消息队列：高并发，轻量级，低延迟，吞吐量不大，对持久化要求不高的场景

Kafka消息队列：高吞吐量，实时流式处理，持久化，高可用在至100k+/sec，多一次语义

Mq:轻量级消息，高可用在20k+/sec，快速响应，更好的事务控制，更复杂的路由支持，和更多开发语言的兼容支持。

分别来说一下：

kafka目前主要作为大数据的流式处理的队列组件，作为大数据的组件，必然是可以处理海量的数据，并且必须具备高可用的特性，是一种分布式的消息队列，保存的数据既有内存中，也有硬盘中，硬盘中的数据默认保留7天。

redis作为目前大热的内存nosql，是一种分布式的内存k-v型数据库，也可以作为消息队列使用，是使用了redis的列表类型，并非专门的消息队列，相比于kafka而言，无法处理海量的数据，但是读取速度由于是内存读取，速度相对较快。

mq作为传统的消息队列，主要应用于传统项目，相对于前二者而言不具备分布式高可用特性。

可按需求来使用。

KAFKA

本人所在的公司使用kafa作为ETL数据通道，通过kafka配套的connect和schemaRegisty来方便快速实现异构数据源的相互转换和存储，通过connect插件生产和消费数据，通过schemaRegisty转换异构数据（可以在几乎所有你知道的数据源之间相互转换），并且数据可以重复被消费（可以通过配置指定数据存储时长）。kafka的开发团队围绕着kafka开发了一整套自成体系的生态圈（confluent platform）。

优点：

1. 可扩展。Kafka集群可以透明的扩展，增加新的服务器进集群。
2. 高性能。Kafka性能远超过传统的ActiveMQ、RabbitMQ等，Kafka支持Batch操作。
3. 容错性。Kafka每个Partition数据会***到几台服务器，当某个Broker失效时，Zookeeper将通知生产者和消费者从而使用其他的Broker。

缺点：

1. 重复消息。Kafka保证每条消息至少送达一次，虽然几率很小，但一条消息可能被送达多次。
2. 消息乱序。Kafka某一个固定的Partition内部的消息是保证有序的，如果一个Topic有多个Partition，partition之间的消息送达不保证有序。
3. 复杂性。Kafka需要Zookeeper的支持，Topic一般需要人工创建，部署和维护比一般MQ成本更高。

MQ

消息队列中间件还有很多种,列举几个:

RocketMq，是阿里在充分reviewkafka代码后，开发的metaQ。在不断更新，修补以后，阿里把metaQ3.0更名为rocket，并且rocket是j***a写的易于维护。

RabbitMQ,支持对消息的可靠的传递，支持事务，不支持批量的操作；基于存储的可靠性的要求存储可以***用内存或者硬盘。

REDIS

[免责声明]本文来源于网络，不代表本站立场，如转载内容涉及版权等问题，请联系邮箱:83115484@qq.com，我们会予以删除相关文章，保证您的权利。转载请注明出处：http://www.pj1663.com/post/1645.html