中间件

准备 准备数据库服务，这里作为学习用，我们就用一个数据库服务。dhost1： localhost 在dhost1服务创建三个数据库 123CREATE DATABASE db1 CHARACTER SET 'utf8'; CREATE DATABASE db2 CHARACTER SET 'utf8'; CREATE DATABASE db3 CHARACTER SET 'utf8'; 配置好dataHost dataNode 12345678910111213<mycat:schema xmlns:mycat="http://io.mycat/"> <!-- 注意：里面的元素一定要按 schema 、dataNode 、 dataHost的顺序配置 -->0 <schema name="mydb" checkSQLschema="true" sqlMaxLimit="100" dataNode...

RabbitMQ的高可用RabbitMQ基于主从模式实现高可用。RabbitMQ有三种模式：单机模式，普通集群模式，镜像集群模式。 单机模式：单机模式就是demo级别的，生产中不会有人使用。 普通集群模式普通集群模式就是在多台机器上启动多个rabbitmq实例，每个机器启动一个。但是创建的queue只会放在一个rabbitmq实例上面，但是其他的实例都同步了这个queue的元数据。在你消费的时候，如果连接到了另一个实例，他会从拥有queue的那个实例获取消息然后再返回给你。 这种方式并没有做到所谓消息的高可用，就是个普通的集群，这样还会导致要么消费者每次随机连接一个实例然后拉取数据，这样的话在实例之间会产生网络传输，增加系统开销，要么固定连接那个queue所在的实例消费，这样会导致单实例的性能瓶颈。 而且如果那个放queue的实例宕机了，会导致接下来其他实例都无法拉取数据；如果没有开启消息的持久化会丢失消息；就算开启了消息的持久化，消息不一定会丢，但是也要等这个实例恢复了，才可以继续拉取数据。所以这个并没有提供高可用，这种方案只是提高了吞吐量，也就是让集群中多个节点来服务某个...

幂等性 幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“setTrue()”函数就是一个幂等函数,无论多次执行，其结果都是一样的.更复杂的操作幂等保证是利用唯一交易号(流水号)实现. 简单来说，幂等性就是一个数据或者一个请求，给你重复来了多次，你得确保对应的数据是不会改变的，不能出错。 出现重复消费场景 首先，比如rabbitmq、rocketmq、kafka，都有可能会出现消息重复消费的问题。因为这个问题通常不是由mq来保证的，而是消费方自己来保证的。 举例kafka来说明重复消费问题:kafka有一个叫做offset的概念，就是每个消息写进去，都有一个offset代表他的序号，然后consumer消费了数据之后，每隔一段时间，会把自己消费过的消息的offset提交一下，代表我已经消费过了，下次就算重启，k...

mq原则数据不能多，也不能少，不能多是说消息不能重复消费。如果mq传递的是非常核心的消息，支撑核心的业务，那么这种场景是一定不能丢失数据的。 丢失数据场景丢数据一般分为两种，一种是mq把消息丢了，一种就是消费时将消息丢了。下面从rabbitmq和kafka分别说一下，丢失数据的场景。 rabbitmq生产者弄丢了数据生产者将数据发送到rabbitmq的时候，可能在传输过程中因为网络等问题而将数据弄丢了。 rabbitmq自己丢了数据如果没有开启rabbitmq的持久化，那么rabbitmq一旦重启，那么数据就丢了。所依必须开启持久化将消息持久化到磁盘，这样就算rabbitmq挂了，恢复之后会自动读取之前存储的数据，一般数据不会丢失。除非极其罕见的情况，rabbitmq还没来得及持久化自己就挂了，这样可能导致一部分数据丢失。 消费端弄丢了数据主要是因为消费者消费时，刚消费到，还没有处理，结果消费者就挂了，这样你重启之后，rabbitmq就认为你已经消费过了，然后就丢了数据。 kafka生产者弄丢了数据生产者没有设置相应的策略，发送过程中丢失数据。 kafka弄丢了数据比较常见的...

大量消息在mq里积压了几个小时了还没解决场景：几千万条数据在MQ里积压了七八个小时，从下午4点多，积压到了晚上很晚，10点多，11点多。线上故障了，这个时候要不然就是修复consumer的问题，让他恢复消费速度，然后傻傻的等待几个小时消费完毕。这个肯定不行。一个消费者一秒是1000条，一秒3个消费者是3000条，一分钟是18万条，1000多万条。所以如果你积压了几百万到上千万的数据，即使消费者恢复了，也需要大概1小时的时间才能恢复过来。 解决方案：这种时候只能操作临时扩容，以更快的速度去消费数据了。具体操作步骤和思路如下： 先修复consumer的问题，确保其恢复消费速度，然后将现有consumer都停掉。 临时建立好原先10倍或者20倍的queue数量(新建一个topic，partition是原来的10倍)。 然后写一个临时分发消息的consumer程序，这个程序部署上去消费积压的消息，消费之后不做耗时处理，直接均匀轮询写入临时建好分10数量的queue里面。 紧接着征用10倍的机器来部署consumer，每一批consumer消费一个临时queue的消息。 这种做...

为什么要保证顺序消息队列中的若干消息如果是对同一个数据进行操作，这些操作具有前后的关系，必须要按前后的顺序执行，否则就会造成数据异常。举例：比如通过mysql binlog进行两个数据库的数据同步，由于对数据库的数据操作是具有顺序性的，如果操作顺序搞反，就会造成不可估量的错误。比如数据库对一条数据依次进行了 插入->更新->删除操作，这个顺序必须是这样，如果在同步过程中，消息的顺序变成了 删除->插入->更新，那么原本应该被删除的数据，就没有被删除，造成数据的不一致问题。 出现顺序错乱的场景rabbitmq 一个queue，有多个consumer去消费，这样就会造成顺序的错误，consumer从MQ里面读取数据是有序的，但是每个consumer的执行时间是不固定的，无法保证先读到消息的consumer一定先完成操作，这样就会出现消息并没有按照顺序执行，造成数据顺序错误。 一个queue对应一个consumer，但是consumer里面进行了多线程消费，这样也会造成消息消费顺序错误。 kafka kafka一个topic，一个partition...

LVS搭建Nginx集群准备工作环境说明共需要三台linux centos服务器，一台LVS，两台RealServer，端口号必须保持一致，设为80，所以需要3台服务器。 设定IP环境如下 服务名 IP 端口 作用 LVS-Director VIP 192.168.120.200 RIP 192.168.120.58 80 运行LVS均衡调度，对外提供虚拟IP访问 RealServer-Nginx1 192.168.120.83 80 运行nginx及tomcat服务，作为真实服务 1 RealServer-Nginx2 192.168.120.58 80 运行nginx及tomcat服务，作为真实服务 2 LVS-Director负责将80端口的请求，负载均衡到Nginx1、Nginx2两台真实服务器上去，接下来我们将进行配置LVS-Director的路由方式-DR，直接路由。准备IP地址信息打印程序balancer-1.0.0.jar，http://hostname:port/server/ip，打印服务器的IP端口号信息。 启动RealServe...