Kafka内外网隔离配置及安装使用 环境版本说明环境：CentOS7版本：JDK1.8、Zookeeper-3.4.14、Kafka2.12-1.0.2JDK安装JDK1.8安装rpm -ivh jdk-8u261-linux-x64.rpm环境变量配置vim /etc/profile最后一行加上配置export JAVA_HOME=/usr/java/jdk1.8.0_261-amd64 export PATH=$PATH:$JAVA_HOME/binjdk验证java -versionZookeeper安装安装tar -zxf zookeeper-3.4.14.tar.gz -C /opt环境变量配置vim /etc/profileZOOKEEPER_PREFIX指向Zookeeper的解压目录export ZOOKEEPER_PREFIX=/opt/zookeeper-3.4.14将Zookeeper的bin目录添加到PATH中export PATH=$PATH:$ZOOKEEPER_PREFIX/bin设置环境变量ZOO_LOG_DIR，指定Zookeeper保存日志的位置export ZOO_LOG_DIR=/var/zookeeper/log使配置生效source /etc/profile修改zookeeper配置cd conf cp zoo_sample.cfg zoo.cfg修改配置文件zoo.cfgvi zoo.cfg修改zookeeper数据存放位置配置修改前dataDir=/tmp/zookeeper修改后dataDir=/var/zookeeper/data启动zookeeper进入zookeeper安装目录=/var/zookeeper/bin启动zookeeperzkServer.sh start查看zookeeper状态zkServer.sh statusKafka安装安装kafkatar -zxf kafka_2.12-1.0.2.tgz -C /opt修改环境变量vi /etc/profile最后加上配置export KAFKA_HOME=/opt/kafka_2.12-1.0.2 export PATH=$PATH:$KAFKA_HOME/bin使配置生效source /etc/profile修改kafka配置修改server.properties配置文件vi server.properties修改链接zookeeper地址：123行修改前zookeeper.connect=localhost:2181修改后zookeeper.connect=localhost:2181/mykafka说明：表示在zookeeper目录下会创建一个mykafka节点修改消息持久化目录：60行修改前log.dirs=/tmp/kafka-logs修改后log.dirs=/var/kafka/kafka-logs创建持久化目录文件夹mkdir -p /var/kafka/kafka-logs脚本说明cd /opt/kafka_2.12-1.0.2/bin说明：kafka-topics.sh 操作主题的 kafka-server-start.sh kafka启动 kafka-server-stop.sh kafka关闭 kafka-console-consumer.sh 命令行里使用消费者 kafka-console-producer.sh 命令行里面使用的生产者启动kafka注意是进入到bin目录下的kafka-server-start.sh ../config/server.properties客户端测试使用zookeeper客户端登录zookeeper，复制启动窗口执行zkCli.sh。（注意：必须复制服务器启动窗口来执行，不然没有脚本。）zkCli.sh查看zookeeper的根节点ls /查看mykafkals /mykafka说明：cluster 集群 controller 控制器 controller_epoch 控制器纪元数据 brokers broker admin 管理者 isr_change_notification 同步的副本 consumers 消费者 log_dir_event_notification log_dir事件通知 latest_producer_id_block 最后一个生产者 config 配置客户端退出zookeeperquit关闭kafkakafka-server-stop.sh主题后台启动kafkakafka-server-start.sh -daemon /opt/kafka_2.12-1.0.2/config/server.properties查看kafka进程信息ps aux | grep kafka主题脚本使用帮助，直接执行脚本，显示主题脚本使用参数。kafka-topics.sh使用参数如下：[root@default-dev bin]# kafka-topics.sh Create, delete, describe, or change a topic. Option Description ------ ----------- --alter Alter the number of partitions, replica assignment, and/or configuration for the topic. --config <String: name=value> A topic configuration override for the topic being created or altered.The following is a list of valid configurations: cleanup.policy compression.type delete.retention.ms file.delete.delay.ms flush.messages flush.ms follower.replication.throttled. replicas index.interval.bytes leader.replication.throttled.replicas max.message.bytes message.format.version message.timestamp.difference.max.ms message.timestamp.type min.cleanable.dirty.ratio min.compaction.lag.ms min.insync.replicas preallocate retention.bytes retention.ms segment.bytes segment.index.bytes segment.jitter.ms segment.ms unclean.leader.election.enable See the Kafka documentation for full details on the topic configs. --create Create a new topic. --delete Delete a topic --delete-config <String: name> A topic configuration override to be removed for an existing topic (see the list of configurations under the --config option). --describe List details for the given topics. --disable-rack-aware Disable rack aware replica assignment --force Suppress console prompts --help Print usage information. --if-exists if set when altering or deleting topics, the action will only execute if the topic exists --if-not-exists if set when creating topics, the action will only execute if the topic does not already exist --list List all available topics. --partitions <Integer: # of partitions> The number of partitions for the topic being created or altered (WARNING: If partitions are increased for a topic that has a key, the partition logic or ordering of the messages will be affected --replica-assignment <String: A list of manual partition-to-broker broker_id_for_part1_replica1 : assignments for the topic being broker_id_for_part1_replica2 , created or altered. broker_id_for_part2_replica1 : broker_id_for_part2_replica2 , ...> --replication-factor <Integer: The replication factor for each replication factor> partition in the topic being created. --topic <String: topic> The topic to be create, alter or describe. Can also accept a regular expression except for --create option --topics-with-overrides if set when describing topics, only show topics that have overridden configs --unavailable-partitions if set when describing topics, only show partitions whose leader is not available --under-replicated-partitions if set when describing topics, only show under replicated partitions --zookeeper <String: urls> REQUIRED: The connection string for the zookeeper connection in the form host:port. Multiple URLS can be given to allow fail-over. 注意：REQUIRED为必选参数，如上面的--zookeeper链接地址。查看所有可用主题kafka-topics.sh --zookeeper localhost:2181/mykafka --list创建主题kafka-topics.sh --zookeeper localhost/mykafka --create --topic topic_1 --partitions 1 --replication-factor 1说明：zookeeper端口可省略，使用的是默认的。--topic： 创建主题名字--partitions：创建几个分区，便于横向扩展。--replication-factor：一个分区创建几个副本，高可用。注意：当只有一个服务一个broker时，是没有意义的，当服务宕机了，数据也没了。因此--replication-factor副本必须在不同的kafka服务器上，才能实现高可用。再次查看可用主题kafka-topics.sh --zookeeper localhost:2181/mykafka --list查看主题详细信息kafka-topics.sh --zookeeper localhost/mykafka --describe --topic topic_1说明：topic_1有一个0号分区，在0号服务器上。实例创建一个topc_2主题，5个分区，每个分区1个副本.kafka-topics.sh --zookeeper localhost/mykafka --create --topic topic_2 --partitions 5 --replication-factor 1查看可用主题kafka-topics.sh --zookeeper localhost:2181/mykafka --list查看topic_2主题详情kafka-topics.sh --zookeeper localhost/mykafka --describe --topic topic_2说明：5个分区都在0号服务器上。消费消费脚本使用帮助：kafka-console-consumer.sh使用参数：The console consumer is a tool that reads data from Kafka and outputs it to standard output. Option Description ------ ----------- --blacklist <String: blacklist> Blacklist of topics to exclude from consumption. --bootstrap-server <String: server to REQUIRED (unless old consumer is connect to> used): The server to connect to. --consumer-property <String: A mechanism to pass user-defined consumer_prop> properties in the form key=value to the consumer. --consumer.config <String: config file> Consumer config properties file. Note that [consumer-property] takes precedence over this config. --csv-reporter-enabled If set, the CSV metrics reporter will be enabled --delete-consumer-offsets If specified, the consumer path in zookeeper is deleted when starting up --enable-systest-events Log lifecycle events of the consumer in addition to logging consumed messages. (This is specific for system tests.) --formatter <String: class> The name of a class to use for formatting kafka messages for display. (default: kafka.tools. DefaultMessageFormatter) --from-beginning If the consumer does not already have an established offset to consume from, start with the earliest message present in the log rather than the latest message. --group <String: consumer group id> The consumer group id of the consumer. --isolation-level <String> Set to read_committed in order to filter out transactional messages which are not committed. Set to read_uncommittedto read all messages. (default: read_uncommitted) --key-deserializer <String: deserializer for key> --max-messages <Integer: num_messages> The maximum number of messages to consume before exiting. If not set, consumption is continual. --metrics-dir <String: metrics If csv-reporter-enable is set, and directory> this parameter isset, the csv metrics will be output here --new-consumer Use the new consumer implementation. This is the default, so this option is deprecated and will be removed in a future release. --offset <String: consume offset> The offset id to consume from (a non- negative number), or 'earliest' which means from beginning, or 'latest' which means from end (default: latest) --partition <Integer: partition> The partition to consume from. Consumption starts from the end of the partition unless '--offset' is specified. --property <String: prop> The properties to initialize the message formatter. --skip-message-on-error If there is an error when processing a message, skip it instead of halt. --timeout-ms <Integer: timeout_ms> If specified, exit if no message is available for consumption for the specified interval. --topic <String: topic> The topic id to consume on. --value-deserializer <String: deserializer for values> --whitelist <String: whitelist> Whitelist of topics to include for consumption. --zookeeper <String: urls> REQUIRED (only when using old consumer): The connection string for the zookeeper connection in the form host:port. Multiple URLS can be given to allow fail-over. REQUIRED：必填参数unless old consumer is used:使用老消费者--bootstrap-server <String: server to REQUIRED (unless old consumer is connect to> used): The server to connect to. only when using old consumer：使用旧消费时使用--zookeeper <String: urls> REQUIRED (only when using old consumer): The connection string for the zookeeper connection in the form host:port. Multiple URLS can be given to allow fail-over.消费者消费链接Kafka服务端，当有多台Kafka时，只需要链接其中一台服务即可。注意，消费者消费端口是9092了。kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic topic_1说明：--bootstrap-server localhost:9092：指定kafka服务地址端口--topic topic_1：指定消费的主题测试界面像是卡住了，不管。消费者API使用参数配置说明生产生产脚本使用帮助kafka-console-producer.sh使用参数：Read data from standard input and publish it to Kafka. Option Description ------ ----------- --batch-size <Integer: size> Number of messages to send in a single batch if they are not being sent synchronously. (default: 200) --broker-list <String: broker-list> REQUIRED: The broker list string in the form HOST1:PORT1,HOST2:PORT2. --compression-codec [String: The compression codec: either 'none', compression-codec] 'gzip', 'snappy', or 'lz4'.If specified without value, then it defaults to 'gzip' --key-serializer <String: The class name of the message encoder encoder_class> implementation to use for serializing keys. (default: kafka. serializer.DefaultEncoder) --line-reader <String: reader_class> The class name of the class to use for reading lines from standard in. By default each line is read as a separate message. (default: kafka. tools. ConsoleProducer$LineMessageReader) --max-block-ms <Long: max block on The max time that the producer will send> block for during a send request (default: 60000) --max-memory-bytes <Long: total memory The total memory used by the producer in bytes> to buffer records waiting to be sent to the server. (default: 33554432) --max-partition-memory-bytes <Long: The buffer size allocated for a memory in bytes per partition> partition. When records are received which are smaller than this size the producer will attempt to optimistically group them together until this size is reached. (default: 16384) --message-send-max-retries <Integer> Brokers can fail receiving the message for multiple reasons, and being unavailable transiently is just one of them. This property specifies the number of retires before the producer give up and drop this message. (default: 3) --metadata-expiry-ms <Long: metadata The period of time in milliseconds expiration interval> after which we force a refresh of metadata even if we haven't seen any leadership changes. (default: 300000) --old-producer Use the old producer implementation. --producer-property <String: A mechanism to pass user-defined producer_prop> properties in the form key=value to the producer. --producer.config <String: config file> Producer config properties file. Note that [producer-property] takes precedence over this config. --property <String: prop> A mechanism to pass user-defined properties in the form key=value to the message reader. This allows custom configuration for a user- defined message reader. --queue-enqueuetimeout-ms <Integer: Timeout for event enqueue (default: queue enqueuetimeout ms> 2147483647) --queue-size <Integer: queue_size> If set and the producer is running in asynchronous mode, this gives the maximum amount of messages will queue awaiting sufficient batch size. (default: 10000) --request-required-acks <String: The required acks of the producer request required acks> requests (default: 1) --request-timeout-ms <Integer: request The ack timeout of the producer timeout ms> requests. Value must be non-negative and non-zero (default: 1500) --retry-backoff-ms <Integer> Before each retry, the producer refreshes the metadata of relevant topics. Since leader election takes a bit of time, this property specifies the amount of time that the producer waits before refreshing the metadata. (default: 100) --socket-buffer-size <Integer: size> The size of the tcp RECV size. (default: 102400) --sync If set message send requests to the brokers are synchronously, one at a time as they arrive. --timeout <Integer: timeout_ms> If set and the producer is running in asynchronous mode, this gives the maximum amount of time a message will queue awaiting sufficient batch size. The value is given in ms. (default: 1000) --topic <String: topic> REQUIRED: The topic id to produce messages to. --value-serializer <String: The class name of the message encoder encoder_class> implementation to use for serializing values. (default: kafka. serializer.DefaultEncoder) 注意：REQUIRED必填参数生产者链接kafka服务kafka-console-producer.sh --broker-list localhost:9092 --topic topic_1说明：--broker-list：指定broker，如果有很多太kafka服务器，只需要指定2个地址接口，这里只有一台kafka服务器，只指定一个。--topic：指定要发送消息到那个topic主题。此时生产者窗口也像卡住了，说明进入了发送消息界面。生产者API使用参数配置说明消息发送接收测试注意：提示如下信息检查主题名称是否错误WARN [Producer clientId=console-producer] Error while fetching metadata with correlation id 8可查看可用主题：明确消费主题和生产者是否是使用的一个主题。kafka-topics.sh --zookeeper localhost:2181/mykafka --list消息的发送与接受测试结果：注意：当关闭消费者后，生产者继续发送消息，当生产者重新链接后，只能接受到后面生产者重新发送的消息。消费历史消息如果要消费以前的消息可以指定参数--from-beginningkafka-console-consumer.sh --bootstrap-server localhost:9092 --topic topic_1 --from-beginning查看持久化数据ca /var/kafka/kafka-logs可以看到很多偏移量的文件。服务端参数配置主要是服务器kafka配置文件server.properties的配置zookeeper.connect该参数用于配置kafka要链接的Zookeeper/集群地址。它的值是一个字符串，使用都好分割zookeeper的多个地址。Zookeeper的单个地址是host:port形式的，可以在最后添加kafka在zookeeper中的根节点路径。例如： zookeeper.connect=192.1681.1:2181，192.1681.2:2181，192.1681.3:2181，192.1681.4:2181/mykafka最好服务器地址数量过半，后面zookeeper存放路径/mykafka写一个就好了。listeners用于指定当前Broker向外发布服务的地址和端口。与advertised.listeners配合，用于做内外网隔离。注意：端口号也是可以修改的。内外网隔离配置listeners用于配置broker监听的URL以及监听器名称列表，使用逗号隔开多个URL及监听器名称。例如：服务器有2个ip，ip如下则配置如下：listeners配置：注意监听器名称不能相同，端口不能相同。PLAINTEXT代表了都使用PLAINTEXT协议，也代表了监听器的名称，但是名称又不能相同，因此使用映射配置参数listner.sercurity.protocol.map。加上上面配置后，启动还是会报错，因此必须加上如下配置：整体说明：注意kafka是使用的PLAINTEXT协议listener.security.protocol.map=INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT listeners=INTERNAL://10.0.2.15:9000,EXTERNAL://192.168.56.30:9001 advertised.listeners=EXTERNAL://192.168.56.30:9001 inter.broker.listener.name=EXTERNALlistener.security.protocol.map：解决监听协议、监听器名称一样问题。listeners：集群多台服务地址advertised.listeners：暴露给消费者生产者,以及节点间通讯使用的地址和端口(需要将该地址发布到zookeeper供客户端使用，如果客户端使用的地址与listeners配置不同)，而另一个地址端口INTERNAL://10.0.2.15:9000则可用于内部管理kafka。inter.broker.listener.name：暴力给消费者生产者使用监听的监听器名称，如果要暴露多个直接可以逗号隔开多加几个，前提是listeners里面有的。listener.security.protocol.map用于内外网隔离配置，监听器名称和安全协议的映射配置。例如：将内外网隔离，即使他们都使用SSL，上面的配置问题就可以加下面参数解决。listener.security.protocol.map=INTERNAL:SSL,EXTERNAL:SSL说明：INTERNAL，EXTERNAL：代表监听器名称SSL：代表都是使用SSL协议。加上这个参数配置，就可以解决上面的监听器名称和协议冲突的问题了。注意：每个监听器的名称只能在map中出现一次。如果监听器名称代表的不是安全协议，必须配置listener.security.protocol.map。每个监听器必须使用不同的网络端口。查看zoopeeper信息：客户端脚本链接zookeeper：zkCli.sh查看kafka信息get /mykafka/brokers/ids/0查看可用主题：kafka-topics.sh --zookeeper localhost:2181/mykafka --listbroker.id该属性用于唯一标记一个kafka的Broker，它的值是一个任意integer值。当kafka以分布式集群部署使用时，非常重要。最好该值只跟该Broker所在的物理主机有关的，如主机名为host1.yanxizhu.com，则broker.id=1，如果主机名为192.168.56.30，则broker.id=30.log.dir通过该属性的值，指定kafka在磁盘上保存消息的日志片段的目录。它时一组用逗号分隔的本地文件系统路径。如果指定了多个路径，那么broker会根据”最少使用“原则，把同一个分区的日志片段保存到同一个路径下。broker会往拥有最少数目分区的路径新增分区，而不是往拥有最小磁盘空间的路径新增分区。

docker部署kafka Docker部署Kafka一、拉取镜像docker pull wurstmeister/zookeeper docker pull wurstmeister/kafka二、启动zookpeerdocker run -d --name zookeeper -p 2181:2181 -t wurstmeister/zookeeper三、启动kafkadocker run -d --name kafka \ -p 9092:9092 \ -e KAFKA_BROKER_ID=0 \ -e KAFKA_ZOOKEEPER_CONNECT=192.168.56.10:2181 \ -e KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://192.168.56.10:9092 \ -e KAFKA_LISTENERS=PLAINTEXT://0.0.0.0:9092 wurstmeister/kafka注意修改自己ip地址四、测试1、进入kafka容器docker exec -it kafka bash2、进入kafak脚本目录cd /opt/kafka_2.13-2.8.1/bin注意修改自己kafka版本3、创建主题kafka-topics.sh --create --zookeeper 192.168.56.10:2181 --replication-factor 1 --partitions 1 --topic topic_1 这里创建了一个topic_1主题。4、添加消息生产者发送消息kafka-console-producer.sh --broker-list 192.168.56.10:9092 --topic topic_1此时进入发送消息界面：5、消费消息消费者消费消息kafka-console-consumer.sh --bootstrap-server 192.168.56.10:9092 --topic topic_1 --from-beginning测试进入消费消息窗口：

MyCat的安装及使用 MyCat的安装及使用一、MyCat的安装1、环境准备​ 本次课程使用的虚拟机环境是centos6.5，首先准备四台虚拟机，安装好mysql，方便后续做读写分离和主从复制。192.168.85.111 node01 192.168.85.112 node02 192.168.85.113 node03 192.168.85.114 node04​ 安装jdk​ 使用rpm的方式直接安装jdk，配置好具体的环境变量2、安装​ 从官网下载需要的安装包，并且上传到具体的虚拟机中，我们在使用的时候将包上传到node01这台虚拟机，由node01充当MyCat。​ 下载地址为：http://dl.mycat.org.cn/1.6.7.5/2020-4-10/解压文件到/usr/local文件夹下tar -zxvf Mycat-server-1.6.7.5-release-20200422133810-linux.tar.gz -C /usr/local配置环境变量vi /etc/profile 添加如下配置信息： export MYCAT_HOME=/usr/local/mycat export PATH=$MYCAT_HOME/bin:$PATH:$JAVA_HOME/bin当执行到这步的时候，其实就可以启动了，但是为了能正确显示出效果，最好修改下MyCat的具体配置，让我们能够正常进行访问。3、配置MyCat​ 进入到/usr/local/mycat/conf目录下，修改该文件夹下的配置文件1、修改server.xml文件<?xml version="1.0" encoding="UTF-8"?> <!-- - - Licensed under the Apache License, Version 2.0 (the "License"); - you may not use this file except in compliance with the License. - You may obtain a copy of the License at - - http://www.apache.org/licenses/LICENSE-2.0 - - Unless required by applicable law or agreed to in writing, software - distributed under the License is distributed on an "AS IS" BASIS, - WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. - See the License for the specific language governing permissions and - limitations under the License. --> <!DOCTYPE mycat:server SYSTEM "server.dtd"> <mycat:server xmlns:mycat="http://io.mycat/"> <user name="root" defaultAccount="true"> <property name="password">123456</property> <property name="schemas">TESTDB</property> <property name="defaultSchema">TESTDB</property> </user> </mycat:server>2、修改schema.xml文件<?xml version="1.0"?> <!DOCTYPE mycat:schema SYSTEM "schema.dtd"> <mycat:schema xmlns:mycat="http://io.mycat/"> <schema name="TESTDB" checkSQLschema="false" sqlMaxLimit="100" dataNode="dn1"> </schema> <dataNode name="dn1" dataHost="host1" database="msb" /> <dataHost name="host1" maxCon="1000" minCon="10" balance="0" writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100"> <heartbeat>select user()</heartbeat> <writeHost host="hostM1" url="192.168.85.111:3306" user="root" password="123456"> <readHost host="hostS1" url="192.168.85.112:3306" user="root" password="123456"></readHost> </writeHost> </dataHost> </mycat:schema>4、启动mycat​ mycat的启动有两种方式，一种是控制台启动，一种是后台启动，在初学的时候建议大家使用控制台启动的方式，当配置文件写错之后，可以方便的看到错误，及时修改，但是在生产环境中，使用后台启动的方式比较稳妥。​ 控制台启动：去mycat/bin目录下执行 ./mycat console​ 后台启动：去mycat/bin目录下执行 ./mycat start​ 按照如上配置在安装的时候应该不会报错，如果出现错误，根据错误的提示解决即可。5、登录验证​ 管理窗口的登录​ 从另外的虚拟机去登录访问当前MyCat，输入如下命令即可mysql -uroot -p123456 -P 9066 -h 192.168.85.111​ 此时访问的是MyCat的管理窗口，可以通过show @@help查看可以执行的命令​ 数据窗口的登录​ 从另外的虚拟机去登录访问MyCat，输入命令如下：mysql -uroot -p123456 -P8066 -h 192.168.85.111​ 当都能够成功的时候以为着mycat已经搭建完成。二、读写分离​ 通过MyCat和MySQL的主从复制配合搭建数据库的读写分离，可以实现MySQL的高可用性，下面我们来搭建MySQl的读写分离。1、一主一从(主从复制的原理之前讲解过了，需要的同学自行参阅文档)1、在node01上修改/etc/my.cnf的文件#mysql服务唯一id，不同的mysql服务必须拥有全局唯一的id server-id=1 #启动二进制日期 log-bin=mysql-bin #设置不要复制的数据库 binlog-ignore-db=mysql binlog-ignore-db=information-schema #设置需要复制的数据库 binlog-do-db=msb #设置binlog的格式 binlog_format=statement2、在node02上修改/etc/my.cnf文件#服务器唯一id server-id=2 #启动中继日志 relay-log=mysql-relay3、重新启动mysql服务4、在node01上创建账户并授权slavegrant replication slave on *.* to 'root'@'%' identified by '123456'; --在进行授权的时候，如果提示密码的问题，把密码验证取消 set global validate_password_policy=0; set global validate_password_length=1;5、查看master的状态show master status6、在node02上配置需要复制的主机CHANGE MASTER TO MASTER_HOST='192.168.85.111',MASTER_USER='root',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=437;7、启动从服务器复制功能start slave;8、查看从服务器状态show slave status\G​ 当执行完成之后，会看到两个关键的属性Slave_IO_Running，Slave_SQL_Running，当这两个属性都是yes的时候，表示主从复制已经准备好了，可以进行具体的操作了2、一主一从验证​ 下面我们通过实际的操作来验证主从复制是否完成。--在node01上创建数据库 create database msb; --在node01上创建具体的表 create table mytbl(id int,name varchar(20)); --在node01上插入数据 insert into mytbl values(1,'zhangsan'); --在node02上验证发现数据已经同步成功，表示主从复制完成​ 通过MyCat实现读写分离​ 在node01上插入如下sql语句，-- 把主机名插入数据库中 insert into mytbl values(2,@@hostname); -- 然后通过mycat进行数据的访问，这个时候大家发现无论怎么查询数据，最终返回的都是node01的数据,为什么呢？ select * from mytbl;​ 在之前的mycat基本配置中，其实我们已经配置了读写分离，大家还记得readHost和writeHost两个标签吗？<writeHost host="hostM1" url="192.168.85.111:3306" user="root" password="123456"> <readHost host="hostS1" url="192.168.85.112:3306" user="root" password="123456"></readHost> </writeHost>​ 其实我们已经配置过了这两个标签，默认情况下node01是用来完成写入操作的，node02是用来完成读取操作的，但是刚刚通过我们的验证发现所有的读取都是node01完成的，这是什么原因呢？​ 原因很简单，就是因为我们在进行配置的时候在 dataHost 标签中缺失了一个非常重要的属性balance，此属性有四个值，用来做负载均衡的，下面我们来详细介绍​ 1、balance=0 :不开启读写分离机制，所有读操作都发送到当前可用的writehost上​ 2、balance=1:全部的readhost和stand by writehost参与select 语句的负载均衡，简单的说，当双主双从模式下，其他的节点都参与select语句的负载均衡​ 3、balance=2:所有读操作都随机的在writehost，readhost上分发​ 4、balance=3:所有读请求随机的分发到readhost执行，writehost不负担读压力 ​ 当了解了这个参数的含义之后，我们可以将此参数设置为2，就能够看到在两个主机上切换执行了。3、双主双从​ 在上述的一主一从的架构设计中，很容易出现单点的问题，所以我们要想让生产环境中的配置足够稳定，可以配置双主双从，解决单点的问题。​ 架构图如下所示：​ 在此架构中，可以让一台主机用来处理所有写请求，此时，它的从机和备机，以及备机的从机复制所有读请求，当主机宕机之后，另一台主机负责写请求，两台主机互为备机。​ 主机分布如下：编号角色ip主机名1master1192.168.85.111node012slave1192.168.85.112node023master2192.168.85.113node034slave2192.168.85.114node04​ 下面开始搭建双主双从。​ 1、修改node01上的/etc/my.cnf文件#主服务器唯一ID server-id=1 #启用二进制日志 log-bin=mysql-bin # 设置不要复制的数据库(可设置多个) binlog-ignore-db=mysql binlog-ignore-db=information_schema #设置需要复制的数据库 binlog-do-db=msb #设置logbin格式 binlog_format=STATEMENT # 在作为从数据库的时候， 有写入操作也要更新二进制日志文件 log-slave-updates #表示自增长字段每次递增的量，指自增字段的起始值，其默认值是1， 取值范围是1 .. 65535 auto-increment-increment=2 # 表示自增长字段从哪个数开始，指字段一次递增多少，他的取值范围是1 .. 65535 auto-increment-offset=1​ 2、修改node03上的/etc/my.cnf文件#主服务器唯一ID server-id=3 #启用二进制日志 log-bin=mysql-bin # 设置不要复制的数据库(可设置多个) binlog-ignore-db=mysql binlog-ignore-db=information_schema #设置需要复制的数据库 binlog-do-db=msb #设置logbin格式 binlog_format=STATEMENT # 在作为从数据库的时候，有写入操作也要更新二进制日志文件 log-slave-updates #表示自增长字段每次递增的量，指自增字段的起始值，其默认值是1，取值范围是1 .. 65535 auto-increment-increment=2 # 表示自增长字段从哪个数开始，指字段一次递增多少，他的取值范围是1 .. 65535 auto-increment-offset=2​ 3、修改node02上的/etc/my.cnf文件#从服务器唯一ID server-id=2 #启用中继日志 relay-log=mysql-relay​ 4、修改node04上的/etc/my.cnf文件#从服务器唯一ID server-id=4 #启用中继日志 relay-log=mysql-relay​ 5、所有主机重新启动mysql服务​ 6、在两台主机node01,node03上授权同步命令GRANT REPLICATION SLAVE ON *.* TO 'root'@'%' IDENTIFIED BY '123456';​ 7、查看两台主机的状态show master status;​ 8、在node02上执行要复制的主机CHANGE MASTER TO MASTER_HOST='192.168.85.111',MASTER_USER='root',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=154;​ 9、在node04上执行要复制的主机CHANGE MASTER TO MASTER_HOST='192.168.85.113',MASTER_USER='root',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=154;​ 10、启动两个从机的slave并且查看状态，当看到两个参数都是yes的时候表示成功start slave; show slave status;​ 11、完成node01跟node03的相互复制--在node01上执行 CHANGE MASTER TO MASTER_HOST='192.168.85.113',MASTER_USER='root',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000001',MASTER_LOG_POS=442; --开启slave start slave --查看状态 show slave status\G --在node03上执行 CHANGE MASTER TO MASTER_HOST='192.168.85.111',MASTER_USER='root',MASTER_PASSWORD='123456',MASTER_LOG_FILE='mysql-bin.000002',MASTER_LOG_POS=442; --开启slave start slave --查看状态 show slave status\G4、双主双从验证在node01上执行如下sql语句：create database msb; create table mytbl(id int,name varchar(20)); insert into mytbl values(1,'zhangsan'); --完成上述命令之后可以去其他机器验证是否同步成功​ 当上述操作完成之后，我们可以验证mycat的读写分离，此时我们需要进行重新的配置，修改schema.xml文件。​ 在当前mysql架构中，我们使用的是双主双从的架构，因此可以将balance设置为1​ 除此之外我们需要注意，还需要了解一些参数：​ 参数writeType，表示写操作发送到哪台机器，此参数有两个值可以进行设置：​ writeType=0:所有写操作都发送到配置的第一个writeHost，第一个挂了切换到还生存的第二个​ writeType=1:所有写操作都随机的发送到配置的writehost中，1.5之后废弃，​ 需要注意的是：writehost重新启动之后以切换后的为准，切换记录在配置文件dnindex.properties中​ 参数switchType:表示如何进行切换：​ switchType=1:默认值，自动切换​ switchType=-1:表示不自动切换​ switchType=2：基于mysql主从同步的状态决定是否切换<?xml version="1.0"?> <!DOCTYPE mycat:schema SYSTEM "schema.dtd"> <mycat:schema xmlns:mycat="http://io.mycat/"> <schema name="TESTDB" checkSQLschema="false" sqlMaxLimit="100" dataNode="dn1"> </schema> <dataNode name="dn1" dataHost="host1" database="msb" /> <dataHost name="host1" maxCon="1000" minCon="10" balance="1" writeType="0" dbType="mysql" dbDriver="native" switchType="1" slaveThreshold="100"> <heartbeat>select user()</heartbeat> <writeHost host="hostM1" url="192.168.85.111:3306" user="root" password="123456"> <readHost host="hostS1" url="192.168.85.112:3306" user="root" password="123456"></readHost> </writeHost> <writeHost host="hostM2" url="192.168.85.113:3306" user="root" password="123456"> <readHost host="hostS2" url="192.168.85.114:3306" user="root" password="123456"></readHost> </writeHost> </dataHost> </mycat:schema>​ 下面开始进行读写分离的验证--插入以下语句，使数据不一致 insert into mytbl values(2,@@hostname); --通过查询mycat表中的数据，发现查询到的结果在node02,node03,node04之间切换，符合正常情况 select * from mytbl; --停止node01的mysql服务 service mysqld stop --重新插入语句 insert into mytbl values(3,@@hostname); --开启node01的mysql服务 service mysqld start --执行相同的查询语句，此时发现在noede01，node02,node04之间切换，符合情况​ 通过上述的验证，我们可以得到一个结论，node01,node03互做备机，负责写的宕机切换，其他机器充作读请求的响应。​ 做到此处，希望大家能够思考一个问题，在上述我们做的读写分离操作，其实都是基于主从复制的，也就是数据同步，但是在生产环境中会存在很多种情况造成主从复制延迟问题，那么我们应该如何解决延迟问题，这是一个值得思考的问题，到底如何解决呢？三、数据切分​ 数据切分指的是通过某种特定的条件，将我们存放在同一个数据库中的数据分散存放到多个数据库上面，以达到分散单台设备负载的效果。​ 数据的切分根据其切分规则的类型，可以分为两种切分模式。一种是按照不同的表来切分到不同的数据库之上，这种切可以称之为数据的垂直切分或者纵向切分，另外一种则是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库上面，这种切分称之为数据的水平切分或者横向切分。​ 垂直切分的最大特点就是 规则简单，实施也更为方便，尤其适合各业务之间的耦合度非常低，相互影响很小，业务逻辑非常清晰的系统。在这种系统中，可以很容易做到将不同业务模块所使用的表分拆到不同的数据库中。根据不同的表来进行拆分，对应用程序的影响也很小，拆分规则也会比较简单清晰。​ 水平切分与垂直切分相比，相对来说稍微复杂一些。因为要将同一个表中的不同数据拆分到不同的数据库中，对于应用程序来说，拆分规则本身就较根据表明来拆分更为复杂，后期的数据维护也会更为复杂一些。1、垂直切分​ 一个数据库由很多表的构成，每个表对应着不同的业务，垂直切分是指按照业务将表进行分类，分布到不同的数据库上面，这样也就将数据或者压力分担到不同的库上面。​ 如上图所示，一个系统被切分成了用户系统、订单交易、支付系统等多个库。​ 一个架构设计较好的应用系统，其总体功能肯定是又多个功能模块所组成的。而每一个功能模块所需要的数据对应到数据库中就是一个或者多个表。而在架构设计中，各个功能模块相关质检的交互点越统一越少，系统的耦合度就越低，系统各个模块的维护性以及扩展性也就越好。这样的系统，实现数据的垂直切分也就越容易。​ 但是往往系统中有些表难以做到完全的独立，存在着跨库join的情况，对于这类的表，就需要去做平衡，是数据让步业务，共用一个数据源还是分成多个库，业务之间通过接口来做调用。在系统初期，数据量比较少，或者资源有限的情况下，会选择共用数据源，但是当数据发展到一定规模，负载很大的情况下就必须要做分割。 ​ 一般来讲业务存在着复杂join的场景是难以切分的，往往业务独立的易于切分。如何切分，切分到何种程度是考验技术架构的一个难题。下面来分析下垂直切分的优缺点：​ 优点：​ 1、拆分后业务清晰，拆分规则明确​ 2、系统之间整合或扩展容易​ 3、数据维护简单​ 缺点：​ 1、部分业务表无法实现join，只能通过接口方式解决，提高了系统复杂度​ 2、受每种业务不同的限制存在单库性能瓶颈，不易数据扩展跟性能提高​ 3、事务处理复杂2、水平切分​ 相对于垂直拆分，水平拆分不是将表做分类，而是按照某个字段的某种规则来分散到多个库中，每个表中包含一部分数据。简单来说，我们可以将数据的水平切分理解为是按照数据行切分，就是将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中，​ ​ 拆分数据就需要定义分片规则。关系型数据库是行列的二维模型，拆分的第一原则是找到拆分维度。比如从会员的角度来分析，商户订单交易类系统中查询会员某天某月某个订单，那么就需要按照会员结合日期来拆分，不同的数据按照会员id做分组，这样所有的数据查询join都会在单库内解决；如果从商户的角度来讲，要查询某个商家某天所有的订单数，就需要按照商户id做拆分；但是如果系统既想按照会员拆分，又想按照商家数据拆分，就会有一定的困难，需要综合考虑找到合适的分片。​ 几种典型的分片规则包括：​ 1、按照用户id取模，将数据分散到不同的数据库，具有相同数据用户的数据都被分散到一个库中；​ 2、按照日期，将不同月甚至日的数据分散到不同的库中；​ 3、按照某个特定的字段求模，或者根据特定范围段分散到不同的库中。​ 如图，切分原则都是根据业务找到适合的切分规则分散到不同的库，下图是用用户id求模的案例：​ 数据做完了水平拆分之后也是有优缺点的。​ 优点：​ 1、拆分规则抽象好，join操作基本可以数据库做；​ 2、不存在单库大数据，高并发的性能瓶颈；​ 3、应用端改造较少；​ 4、提高了系统的稳定性跟负载能力​ 缺点：​ 1、拆分规则难以抽象​ 2、分片事务一致性难以解决​ 3、数据多次扩展跟维护量极大​ 4、跨库join性能较差3、总结​ 数据切分的两种方式，会发现每种方式都有自己的缺点，但是他们之间有共同的缺点，分别是：​ 1、引入了分布式事务的问题​ 2、跨节点join的问题​ 3、跨节点合并排序分页的问题​ 4、多数据源管理的问题​ 针对数据源管理，目前主要有两种思路：​ 1、客户端模式，在每个应用程序模块中配置管理自己需要的一个或多个数据源，直接访问各个数据库，在模块内完成数据的整合​ 2、通过中间代理层来统一管理所有的数据源，后端数据库集群对前端应用程序透明；​ 在实际的生产环境中，我们都会选择第二种方案来解决问题，尤其是系统不断变得庞大复杂的时候，其实这是非常正确的，虽然短期内付出的成本可能会比较大，但是对整个系统的扩展性来说，是非常有帮助的。​ MyCat通过数据切分解决传统数据库的缺陷，又有了nosql易于扩展的优点。通过中间代理层规避了多数据源的数据问题，对应用完全透明，同时对数据切分后存在的问题，也做了解决方案。​ MyCat在做数据切分的时候应该尽可能的遵循以下原则，当然这也是经验之谈，最终的落地实现还是要看具体的应用场景在做具体的分析​ 第一原则：能不切分尽量不要切分​ 第二原则：如果要切分一定要选择合适的切分规则，提前规划好​ 第三原则：数据切分尽量通过数据冗余或表分组来降低跨库join的可能​ 第四原则：由于数据库中间件对数据join实现的优劣难以把握，而且实现高性能难度极大，业务读取尽量少使用多表join。四、MyCat的配置文件讲解​ 在之前的操作中，我们已经做了部分文件的配置，但是具体的属性并没有讲解，下面我们讲解下每一个配置文件具体的属性以及相关的基本配置。1、搞定schema.xml文件​ schema.xml作为MyCat中重要地配置文件之一，管理着MyCat的逻辑库、表、分片规则、DataNode以及DataSource。1、schema标签<schema name="TESTDB" checkSQLschema="false" sqlMaxLimit="100" dataNode="dn1"></schema>​ schema标签用于定义MyCat实例中的逻辑库，MyCat可以有多个逻辑库，每个逻辑库都有自己相关的配置，可以使用schema标签来划分这些不同的逻辑库。如果不配置schame，那么所有的表配置都将属于同一个默认的逻辑库。​ dataNode：该属性用于绑定逻辑库到某个具体的database上。​ checkSQLschema：当该值为true时，如果执行select from TESTDB.user，那么MyCat会将语句修改为select from user,即把表示schema的字符去掉，避免发送到后端数据库执行时报错。​ sqlMaxLimit：当该值设置为某个数值的时候，每次执行的sql语句，如果没有加上limit语句，MyCat也会自动加上对应的值。例如，当设置值为100的时候，那么select from user的效果跟执行select from user limit 100相同。如果不设置该值的话，MyCat默认会把所有的数据信息都查询出来，造成过多的输出，所以，还是建议设置一个具体的值，以减少过多的数据返回。当然sql语句中可以显式的制定limit的大小，不受该属性的约束。2、table标签<table name="travelrecord" dataNode="dn1,dn2,dn3" rule="auto-sharding-long" ></table>​ table标签定义了MyCat中的逻辑表，所有需要拆分的表都需要在这个标签中定义。​ name：定义逻辑表的表名，这个名字就如同创建表的时候指定的表名一样，同个schema标签中定义的名字必须唯一。​ dataNode：定义这个逻辑表所属的dataNode，该属性的值需要和dataNode标签中的name属性值对应，如果需要定义的dn过多，可以使用如下方法减少配置：<table name="travelrecord" dataNode="multipleDn$0-99,multipleDn2$100-199" rule="auto-shardinglong" ></table> <dataNode name="multipleDn$0-99" dataHost="localhost1" database="db$0-99" ></dataNode> <dataNode name="multipleDn2$100-199" dataHost="localhost1" database=" db$100-199" ></dataNode>​ rule：该属性用于指定逻辑表要使用的规则名字，规则名字在rule.xml中定义，必须与tableRule标签中的name属性值一一对应​ ruleRequired：该属性用于指定表是否绑定分片规则，如果配置为true，但没有配置具体rule的话，程序会报错。​ primaryKey：该逻辑表对应真实表的主键，例如：分片的规则是使用非主键进行分片的，那么在使用主键查询的时候，就会发送查询语句到所有配置的DN上，如果使用改属性配置真实表的主键。那么MyCat会缓存主键与具体DN的信息，那么再次使用非主键进行查询的时候就不会进行广播式的查询，就会直接发送语句到具体的DN，但是尽管配置改属性，如果缓存没有命中的话，还是会发送语句给具体的DN来获得数据​ type：该属性定义了逻辑表的类型，目前逻辑表只有全局表和普通表两种类型。对应的配置：​ 全局表：global​ 普通表：不指定该值为global的所有表​ autoIncrement：MySQL 对非自增长主键，使用 last_insert_id()是不会返回结果的，只会返回 0。所以，只有定义了自增长主键的表才可以用 last_insert_id()返回主键值。MyCat目前提供了自增长主键功能，但是如果对应的MySQL节点上数据表，没有定义 auto_increment，那么在MyCat层调用 last_insert_id()也是不会返回结果的。由于 insert 操作的时候没有带入分片键， MyCat 会先取下这个表对应的全局序列，然后赋值给分片键。 这样才能正常的插入到数据库中，最后使用 last_insert_id()才会返回插入的分片键值。如果要使用这个功能最好配合使用数据库模式的全局序列。使用 autoIncrement=“true” 指定这个表有使用自增长主键，这样 MyCat才会不抛出分片键找不到的异常。使用 autoIncrement=“false” 来禁用这个功能，当然你也可以直接删除掉这个属性。默认就是禁用的。 ​ needAddLimit：指定表是否需要自动的在每个语句后面加上limit限制。由于使用了分库分表，数据量有时会特别巨大。这时候执行查询语句，如果恰巧又忘记了加上数量限制的话，那么查询所有的数据出来，就会执行很久的时间，所以mycat自动为我们加上了limit 100。当前如果语句中又limit，那么就不会添加了。3、childTable标签​ childTable标签用于定义ER分片的子表。通过标签上的属性与父表进行关联。​ name：定义子表的表名​ joinKey：插入子表的时候会使用这个列的值查找父表存储的数据节点​ parentKey：属性指定的值一般为与父表建立关联关系的列名。程序首先获取joinkey的值，再通过parentKey属性指定的列名产生查询语句，通过执行该语句得到父表存储再哪个分片上，从而确定子表存储的位置。​ primaryKey：跟table标签所描述相同​ needAddLimit：跟table标签所描述相同4、dataNode标签<dataNode name="dn1" dataHost="lch3307" database="db1" ></dataNode>​ dataNode标签定义了mycat中的数据节点，也就是我们通常说的数据分片，一个dataNode标签就是一个独立的数据分片。​ name：定义数据节点的名字，这个名字需要是唯一的，我们需要再table标签上应用这个名字，来建立表与分片对应的关系​ dataHost：该属性用于定义该分片属于哪个数据库实例，属性值是引用dataHost标签上定义的name属性。​ database：该属性用于定义该分片属性哪个具体数据库实力上的具体库，5、dataHost标签​ 该标签定义了具体的数据库实例、读写分离配置和心跳语句<dataHost name="localhost1" maxCon="1000" minCon="10" balance="0" writeType="0" dbType="mysql" dbDriver="native"> <heartbeat>select user()</heartbeat> <!-- can have multi write hosts --> <writeHost host="hostM1" url="localhost:3306" user="root" password="123456"> <!-- can have multi read hosts --> <!-- <readHost host="hostS1" url="localhost:3306" user="root" password="123456" /> --> </writeHost> <!-- <writeHost host="hostM2" url="localhost:3316" user="root" password="123456"/> --> </dataHost>​ name：唯一标识dataHost标签，供上层的标签使用​ maxcon：指定每个读写实例连接池的最大连接​ mincon：指定每个读写实例连接连接池的最小链接，初始化连接池的大小​ balance：负载均衡类型：​ 0：不开启读写分离机制，所有读操作都发送到当前可用的writeHost上​ 1：全部的readHost和stand by writeHost参与select语句的负载均衡，简单的说，当双主双从模式（M1->S1,M2->S2,并且M1与M2互为主备），正常情况下，M2,S1,S2都参与select语句的负载均衡​ 2：所有读操作都随机的再writeHost、readHost上分发​ 3：所有读请求随机的分发到writeHost对应readHost执行，writeHost不负担读压力，在之后的版本中失效。​ writeType：写类型​ writeType=0：所有的写操作发送到配置的第一个writeHost，第一个挂了切换到还生存的第二个writeHost，重启之后以切换后的为准，切换记录保存在配置文件 dnindex.properties​ writeType=1：所有写操作都随机的发送到配置的writeHost，1.5以后废弃不推荐​ dbType：指定后端连接的数据库类型，如MySQL，mongodb,oracle​ dbDriver：指定连接后端数据库使用的Driver，目前可选的值有native和JDBC。使用native的话，因为这个值执行的是二进制的mysql协议，所以可以使用mysql和maridb，其他类型的数据库则需要使用JDBC驱动来支持。​ switchType：是否进行主从切换​ -1：表示不自动切换​ 1：默认值，自动切换​ 2：基于mysql主从同步的状态决定是否切换6、heartbeat标签​ 这个标签指明用于和后端数据库进行心跳检测的语句。2、搞定server.xml文件​ server.xml几乎保存了所有mycat需要的系统配置信息。<user name="test"> <property name="password">test</property> <property name="schemas">TESTDB</property> <property name="schemas">TESTDB</property> <property name="schemas">TESTDB</property> <property name="schemas">TESTDB</property> <privileges check="false"> <schema name="TESTDB" dml="0010" showTables="custome/mysql"> <table name="tbl_user" dml="0110"></table> <table name="tbl_dynamic" dml="1111"></table> </schema> </privileges> </user> ​ server.xml中的标签本就不多，这个标签主要用于定义登录mycat的用户和权限。​ property标签用来声明具体的属性值，name用来指定用户名，password用来修改密码，readonly用来限制用户是否是只读的，schemas用来控制用户课访问的schema，如果有多个的话，用逗号分隔​ privileges标签是对用户的schema及下级的table进行精细化的DML控制，privileges节点的check属性适用于标识是否开启DML权限检查，默认false标识不检查，当然不配置等同于不检查​ 在进行检查的时候，是通过四个二进制位来标识的，insert，update，select，delete按照顺序标识，0表示未检查，1表示要检查​ system标签表示系统的相关属性：属性含义备注charset字符集设置utf8,utf8mb4defaultSqlParser指定的默认解析器druidparser，fdbparser(1.4之后作废)processors系统可用的线程数，默认为机器CPU核心线程数processorBufferChunk每次分配socket direct buffer的大小默认是4096个字节processorExecutor指定NIOProcessor共享的businessExecutor固定线程池大小，mycat在处理异步逻辑的时候会把任务提交到这个线程池中 sequnceHandlerTypemycat全局序列的类型0为本地文件，1为数据库方式，2为时间戳方式，3为分布式ZK ID生成器，4为zk递增id生成3、rule.xml​ rule.xml里面就定义了我们对表进行拆分所涉及到的规则定义。我们可以灵活的对表使用不同的分片算法，或者对表使用相同的算法但具体的参数不同，这个文件里面主要有tableRule和function这两个标签。1、tableRule​ 这个标签被用来定义表规则，定义的表规则在schema.xml文件中<tableRule name="rule1"> <rule> <columns>id</columns> <algorithm>func1</algorithm> </rule> </tableRule> ​ name属性指定唯一的名字，用来标识不同的表规则​ 内嵌的rule标签则指定对物理表中的哪一列进行拆分和使用什么路由算法​ columns内指定要拆分的列的名字​ algorithm使用function标签中的那么属性，连接表规则和具体路由算法。当然，多个表规则可以连接到同一个路由算法上。2、function<function name="hash-int" class="io.mycat.route.function.PartitionByFileMap"> <property name="mapFile">partition-hash-int.txt</property> </function>​ name指定算法的名字​ class指定路由算法具体的类名字​ property为具体算法需要用到的一些属性

MyCat MyCat一、基础知识1、分布式系统​ 分布式系统是指其组件分布在网络上，组件之间通过传递消息进行通信和动作协调的系统。它的核心理念是让多台服务器协同工作，完成单台服务器无法处理的任务，尤其是高并发或者大数据量的额任务。它的特点是：​ 透明性：分布式系统对于用户是透明的，一个分布式系统在用户面前的表现就像一个传统的单处理机分时系统，可用用户不必了解其内部结构就能使用;​ 扩展性：分布式系统的最大特点是可扩展性，它能够根据需求的增加而扩展，可以通过横向扩展使集群的整体性能得到线性提升，也可以通过纵向扩展单台服务器的性能使服务器集群的性能得到提升;​ 可靠性：分布式系统不允许单点失效的问题存在，它的基本思想是，如果一台机器坏了，则其他机器能够接替它进行工作，具有持续服务的特性;​ 高性能：高性能才是设计分布式系统的初衷.​ 分布式系统的缺点：​ 1、在节点通信部分的开销比较大，线程安全问题也变得复杂，需要在保证数据完整性的同时兼顾性能​ 2、过分依赖网络，网络信息的丢失和饱和将会抵消分布式系统的大部分优势​ 3、有潜在的数据安全和网络安全等安全性问题。2、分布式数据库​ 随着技术的发展，各个行业所产生的数据量呈爆炸式增长，动辄就达到数百TB或者PB的级别，已经远远超过了传统单机数据库的处理能力，因此分布式数据库已经成为了最最迫切的需求。​ 分布式数据库是指数据在物理上分步而在逻辑上集中管理的数据库系统。物理上分步是指分布式数据库的数据分步在物理位置不同并由网络连接的节点或站点上；逻辑上集中是指各数据库节点之间在逻辑上是一个整体，并由统一的数据库管理系统管理，不同的节点分步可以跨不同的机房、城市甚至国家。​ 分布式数据库的特点:​ 透明性：用户不必关系数据的逻辑分区和物理位置分步的细节，也不必关系重复副本的一致性问题，同时不必关系在局部场地上数据库支持哪种数据模型，对于开发工程师而言，当数据库从一个场地移到另一个场地时必须改写应用程序，使用起来如果一个数据库。​ 数据冗余性：分布式数据库通过冗余实现系统的可靠性、可用性，并改善其性能。多个节点存储数据副本，当某一个节点的数据遭到破坏时，冗余的副本可保证数据的完整性；当工作的节点受损害时，可通过心跳等机制进行切换，系统整体不被破坏。还可以通过热点数据的就近分步原则减少网络通信的消耗，加快访问速度，改善性能。​ 易于扩展性：在分布式数据库中能够方便地通过水平扩展提高系统的整体性能，也能够通过垂直扩展来提高性能，扩展并不需要修改系统程序。​ 自治性：各节点上的数据由本地的DBMS管理，具有自治处理能力，完成本场地的应用或局部应用​ 分布式数据库还具有经济、性能优越、响应速度更快、灵活的体系结构、易于继承现有系统等特点。3、分布式数据库的实现原理​ 分布式数据库具有逻辑整体性、物理分布式，正是因为其物理分布性才使得分布式数据库的实现变得更加复杂，因为数据划分后存储在不同的节点上，而为了保证可靠性，需要存储多个副本，所以产生了数据复制的问题。为了保证良好的性能，分布式数据库必须易于扩展，具体来讲分布式数据库应有4个优势：数据分片及复制管理、具有事务的可靠性存取、良好的性能、易于扩展，所以分布式数据库在设计上需要实现数据库数据库的目录管理、数据分片、分布式查询处理、分布式并发控制、分布式锁管理、分布式存储、分布式网络架构、分布式安全管理等。​ 1、分布式数据库的目录管理​ 分布式数据库的目录存放着系统元数据及数据库的元数据的全部信息，这些数据的存在是为了正确、有效地访问数据。数据的增删改查操作都需要用到目录，用户授权、安全管理及并发控制等也都需要用到目录，目录结构的合理性直接影响数据库的性能。目录一般包括各级的描述、访问方法的描述、关于数据库的统计数据和一致性信息等，系统根据这些信息将用户查询转换为物理数据库上的查询，选择一条最佳的存取路径进行事务管理及安全性、完整性检查等。​ 分布式数据库的目录课分为全局目录、分布式目录、全局与本地混合目录。​ 2、数据分片​ 当数据库过于庞大，尤其是写入过于频繁且很难由一台主机支撑时，我们还是会面临扩展瓶颈。我们将存放在同一个数据库实例中的数据分散存放到多个数据库实例上，进行多台设备存取以提高性能，在切分数据的同时可以提高系统整体的可用性。​ 数据分片是指将数据全局地划分为相关的逻辑片段，有水平切分、垂直切分、混合切分三种类型。​ 水平切分：按照某个字段的某种规则分散到多个节点库中，每个节点中包含一部分数据。可以将数据的水平切分简单理解为按照数据行进行切分，就是将表中的某些行却分到一个节点，将另外某些行切分到其他节点，从分布式的整体来看它们是一个整体的表​ 垂直切分：一个数据库由很多表构成，每个表对应不同的业务，垂直切分是指按照业务将表进行分类并分不到不同的节点上，垂直拆分简单明了，拆分规则明确，应用程序模块清晰、明确、容易整合，但是某个表的数据量达到一定程度后扩展起来比较困难。​ 混合切分：水平切分和垂直切分的结合​ 3、分布式查询处理​ 分布式查询处理的任务就是把一个分布式数据库上的高层次查询映射为在本地数据库上的操作，查询的解析必须拆分为代数查询的关系运算序列，将要查询的数据定位到各节点，使得查询在各节点进行，最后通过网络通信的操作汇聚查询结果。​ 4、分布式并发控制​ 并发控制是分布式事务管理的基本任务之一，其目的是保证分布式数据库中的多个事务并发高效、正确的执行。并发控制用来保证事务的可串行性，也就是说事务的并发执行等价于它们按某种次序的串行执行，从而为用户提供并发的透明性。进行并发控制的方法主要有三种：加锁并发控制、时间戳控制、乐观并发控制。加锁并发控制应用广泛，但是容易发生死锁；时间戳控制消除了死锁，一旦发生冲突变回重启而不是等待，需要有全局的统一时钟；乐观并发控制对于冲突较少的系统较为合适，对于冲突多的系统则效率低下。4、OLTP和OLAP​ 在互联网时代，海量数据的存储和访问成为系统设计与使用的瓶颈，对于海量数据处理，按照使用场景，主要分为两种类型：联机事务处理（OLTP）和联级分析处理（OLAP）。​ 联机事务处理也称为面向事务的处理系统，其基本特征是原始数据可以立即传送到计算中心进行处理，在很短的时间内给出处理结果。​ 联级分析处理是指通过多维的方式对数据进行分析、查询和报表，可以同数据挖掘工具、统计分析工具配合使用，增强决策分析功能。 ​ 两者之间的区别: OLTPOLAP系统功能日常交易处理统计、分析、报表DB设计面向实时交易类应用面向统计分析类应用数据处理当前的，最新的细节的，历史的、聚集的、多维的、集成的实时性实时读写要求高实时要求读写低事务强一致性弱事务分析要求低，简单高，复杂5、关系型数据库和NoSQL​ 关系型数据库是建立在关系模型基础上的数据库，其借助于集合代数等数学概念和方法来处理数据库中的数据，主流的是Oracle，DB2,SQL Server,MySQL​ NoSQL数据库，全称为Not Only SQL,意思就是适用关系型数据库的时候就是用关系型数据库，不适用的时候也没必要非使用关系型数据库不可，可以考虑更加合适的数据存储，主要分为临时性键值存储（Memcached，Redis），永久性键值存储（Redis），面向文档的数据库（MongoDB,CouchDB）,面向列的数据库（Cassandra，HBase），每种NoSQL都有其特有的使用场景及优点。 关系型数据库NoSQL数据库特点数据关系模型基于关系模型，结构化存储，完整性约束基于二维表及其之间的联系，需要连接、并、交、差等操作采用结构化的查询语言做数据读写操作需要数据的一致性，需要事务甚至强一致性非结构化的存储基于多维关系模型具有特色的使用场景优点保证数据的一致性可以进行join等复杂查询通用化，技术成熟高并发、大数据下读写能力强支持分布式，易于扩展，可伸缩简单，弱结构化存储缺点数据读写必须经过sql解析，大量数据、高并发读写性能不足对数据做读写，或修改数据结构时需要加锁，影响并发操作无法适应非结构化存储扩展困难昂贵、复杂join等复杂操作能力较弱事务支持较弱通用性差无完整约束复杂业务场景支持较差二、MyCat介绍1、MyCat是什么​ MyCat 是什么？从定义和分类来看，它是一个开源的分布式数据库系统，是一个实现了 MySQL 协议的Server，前端用户可以把它看作是一个数据库代理，用 MySQL 客户端工具和命令行访问，而其后端可以用MySQL 原生（Native） 协议与多个 MySQL 服务器通信，也可以用 JDBC 协议与大多数主流数据库服务器通信，其核心功能是分表分库，即将一个大表水平分割为 N 个小表，存储在后端 MySQL 服务器里或者其他数据库里。​ MyCat 发展到目前的版本，已经不是一个单纯的 MySQL 代理了，它的后端可以支持 MySQL、 SQL Server、Oracle、 DB2、 PostgreSQL 等主流数据库，也支持 MongoDB 这种新型 NoSQL 方式的存储，未来还会支持更多类型的存储。而在最终用户看来，无论是那种存储方式，在 MyCat 里，都是一个传统的数据库表，支持标准的SQL 语句进行数据的操作，这样一来，对前端业务系统来说，可以大幅降低开发难度，提升开发速度，在测试阶段，可以将一个表定义为任何一种 MyCat 支持的存储方式，比如 MySQL 的 MyASIM 表、内存表、或者MongoDB、 LevelDB 以及号称是世界上最快的内存数据库 MemSQL 上。试想一下，用户表存放在 MemSQL 上，大量读频率远超过写频率的数据如订单的快照数据存放于 InnoDB 中，一些日志数据存放于 MongoDB 中，而且还能把 Oracle 的表跟 MySQL 的表做关联查询，你是否有一种不能呼吸的感觉？而未来，还能通过 MyCat 自动将一些计算分析后的数据灌入到 Hadoop 中，并能用 MyCat+Storm/Spark Stream 引擎做大规模数据分析，看到这里，你大概明白了， MyCat 是什么？ MyCat 就是 BigSQL， Big Data On SQL Database。 ​ 对于不同的角色，MyCat到底是个啥？​ 对于DBA而言，可以这么理解MyCat：​ MyCat就是MySQL Server,而Mycat后面连接的MySQL Server,就好像是MySQL的存储引擎，如InnoDB,MyISAM等，因此，MyCat本身并不存储数据，数据是再后端的MySQL上存储的，因此数据可靠性以及事务都是MySQL保证的，简单说，MyCat就s是MySQL最佳伴侣，它再一定程度上让MySQL拥有了能跟Oracle PK的能力。​ 对于软件工程师来说，可以这么理解MyCat:​ MyCat就是一个近似等于MySQL的数据库服务器，你可以用连接MySQL的方式去连接MyCat，除了端口不同，默认的MyCat端口是8066而不是MySQL的3306，因此需要再连接字符串上增加端口信息，大多数情况下，可以用你熟悉的对象映射框架使用MyCat，但建议对于分片表，尽量使用基础的SQL语句，因为这样能达到最佳性能，特别是几千万甚至几百亿条记录的情况下。​ 对于架构师来说，可以这么理解MyCat：​ MyCat是一个强大的数据库中间件，不仅仅可以用作读写分离、以及分库分表、容灾备份，而且可以用于多租户应用开发，云平台基础设施，让你的架构具备很强的适应性和灵活性，借助于即将发布的mycat只能优化模块，系统的数据访问瓶颈和热点一目了然，根据这些统计分析数据，你可以自动或手工调整后端存储，将不同的表映射到不同的存储引擎上，而整个应用的代码一行也不用改变。2、MyCat的原理​ MyCat的原理并不复杂，复杂的是代码，如果代码也不复杂，那么早就成为了一个传说了。​ MyCat的原理中最重要的一个动作是“拦截”，它拦截了用户发送过来的SQL语句，首先对SQL语句做了一些特定的分析：如分片分析、路由分析、读写分离分析、缓存分析等，然后将此SQL发送后端的真实数据库，并将返回的结果做适当的处理，最终再返回给用户。​ 上述图片里，orders表被分为了三个分片DataNode（简称dn），这三个分片是分布在两台MySQL Server上（Datahost），即datanode=database@datahost方式，因此你可以用一台到N台服务器来分片，分片规则为（sharding rule）典型的字符串枚举分片规则，一个规则的定义是分片字段（sharding column）+分片函数（rule function）,这里的分片字段为prov而分片函数为字符串枚举方式。​ 当MyCat收到一个SQL时，会先解析这个SQL,查找涉及到的表，然后看此表的定义，如果有分片规则，则获取到SQL里分片字段的值，并分配分片函数，得到该SQL对应的分片列表，然后将SQL发往这些分片去执行，最后收集和处理所有分片返回的结果数据，并输出到客户端，以select * from orders where prov = ?语句为例，查到prov=wuhan,按照分片函数，wuhan返回dn1,于是sql就发给了mysql1，去取db1上的查询结果，并返回给用户。​ 如果上述sql改为select * from orders where prov in (wuhan,beijing),那么，sql就会发给MySQL1和MySQL2去执行，然后结果集合并后输出给用户。但通常业务中我们的SQL会有order by以及limit翻页语法，此时就设计到结果集在MyCat端的二次处理，这部分代码也比较复杂，而最复杂的则属两个表的join，为此，MyCat提出了创新性的ER分片，全局表，HBT（human brain tech）人工智能的Catlet，以及结合Storm/Spark引擎等十八般武艺的解决办法，从而称为目前业界最强大的方案，这就是开源的力量。3、应用场景​ MyCat发展到现在，使用的场景已经很丰富，而且不断有新用户给出新的创新性的方案，以下是典型的应用场景：​ 1、单纯的读写分离，此时配置最为简单，支持读写分离，主从切换​ 2、分库分表，对于超过1000万的表进行分片，最大支持1000亿的单表分片​ 3、多租户应用，每个应用一个库，但应用程序只连接MyCat，从而不改造程序本身，实现多租户化​ 4、报表系统，借助MyCat的分表能力，处理大规模报表的统计​ 5、整合多数据源​ 6、作为海量数据实时查询的一种简单有效方案，比如100亿条频繁查询的记录需要在3秒内查询出来结果，除了基于主键的查询，还可能存在范围查询或其他属性查询，此时MyCat可能是最简单有效的选择​ 7、数据库路由器，MyCat基于MySQL实例的连接池复用机制，可以让每一个应用最大程度地共享一个MySQL实例的所有连接池，让数据库的并发访问能力大大提升4、为什么使用MyCat​ 1、java与数据库紧耦合​ 2、高访问量高并发对数据库的压力​ 3、读写请求数据不一致5、数据库中间件对比对比项目mycatmangocobarheisenbergaltasamoeba数据切片支持支持支持支持支持支持读写分离支持支持支持支持支持支持宕机自动切换支持不支持支持不支持半支持，影响写不支持mysql协议前后端支持JDBC前端支持前后端支持前后端支持JDBC支持的数据库mysql，oracle，mongodb，postgresqlmysqlmysqlmysqlmysqlmysql，mongodb社区活跃度高活跃停滞低中等停滞文档资料极丰富较齐全较齐全较少中等缺少是否开源开源开源开源开源开源开源是否支持事务弱XA支持单库强一致，分布式弱事务单库强一致，多库弱事务单库强一致，分布弱事务不支持三、MyCat的核心概念​ MyCat是数据库中间件，就是介于数据库与应用之间，进行数据处理和交互的中间服务。从原有的一个库，被切分为多个分片数据库，所有的分片数据库集群构成了整个完整的数据库存储。​ 如上图所示，数据被分到多个分片数据库之后，应用如果需要读取数据，就要处理多个数据源的数据。如果没有数据库中间件，那么应用将直接面对分片集群，数据源切换、事务处理、数据聚合都需要应用直接处理，原本该是专注于业务的应用，将会话大量的工作来处理分片后的问题，最重要的是每个应用处理将是完全的重复造轮子。1、逻辑库​ 对于实际应用而言，其实并不需要知道中间件的存在，开发人员只需要知道数据库的概念即可，所以数据库中间件可以被看作是一个或多个数据库集群构成的逻辑库。​ 在云计算时代，数据库中间件可以以多租户的形式给一个或多个应用提供服务，每个应用访问的可能是一个独立或者共享的物理库，常见的如阿里云数据库服务器RDS2、逻辑表​ 既然有逻辑库，那么就应该有逻辑表，在分布式数据库中，对应用来说，读写数据的表就是逻辑表。逻辑表可以使数据切分后，分步在一个或多个分片库中，也可以不做数据切分，不分片，只有一个表构成3、分片表​ 分片表，是指哪些原有的很大数据的表，需要切分到多个数据库的表，这样每一个分片都会有一部分数据，所有分片构成了完整的数据。4、非分片表​ 一个数据库中并不是所有的表都很大，某些表是可以不用进行切分的，非分片是相对分片表来说的，就是那些不需要进行数据切分的表。5、ER表​ 关系型数据库是基于实体关系模型之上，通过其描述了真实世界中事物与关系，MyCat中的ER表既是来源于此。根据这一思路，提出了基于ER关系的数据分片策略，子表的记录与所关联的父表记录存放在同一个数据分片上，即子类依赖于父类，通过表分组保证数据join不会跨库操作。​ 表分组是解决跨分片数据join的一种很好的思路，也是数据切分规划的重要一条规则。6、全局表​ 一个真实的业务系统中，往往存在大量的类似字典表的表，这些表基本上很少变动，字典表具有以下几个特点：​ 1、变动不频繁​ 2、数据量总体变化不大​ 3、数据规模不大，很少有超过数十万条记录​ 对于这类的表，在分片的情况下，当业务表因为规模而进行分片以后，业务表与这些附属的字典表之间的关联，就成了比较棘手的问题，所以MyCat中通过数据冗余来解决这类表的join，即所有的分片都有一份数据的拷贝，所有将字典表或者符合字典表特性的一些表定义为全局表。​ 数据冗余是解决跨分片数据join的一种很好思路，也是数据切分规划的另外一条重要原则7、分片节点（dataNode）​ 数据切分后，一个大表被分到不同的分片数据库上面，每个表分片所在的数据库就是分片节点（dataNode）8、节点主机（dataHost）​ 数据切分后，每个分片节点（dataNode）不一定都会独占一台机器，同一机器上面可以有多个分片数据库，这样一个或多个分片节点（dataNode）所在的机器就是节点主机（dataHost）,为了规避单节点主机并发数限制，尽量将读写压力高的分片节点（dataNode）均衡的放在不同的节点主机（dataHost）。9、分片规则​ 数据切分是指一个大表被分成若干个分片表，就需要一定的规则，这样按照某种规则把数据分到某个分片的规则就是分片规则，数据切分选择合适的分片规则非常重要，将极大的避免后续数据处理的难度。10、全局序列号​ 数据切分后，原有的关系数据库中的主键约束在分布式条件下将无法使用，因此需要引入外部机制保证数据唯一性标识，这种保证全局性的数据唯一标识的机制就是全局序列号。11、多租户​ 多租户技术或称多重租赁技术，是一种软件架构技术，它是在探讨与实现如何于多用户的环境下共用相同的系统或程序组件，并且扔可确保各用户间数据的隔离性。在云计算时代，多租户技术在共用的数据中心以单一系统架构与服务提供多数客户端相同甚至可定制化的服务，并且仍然可以保障客户的数据隔离。目前各种各样的云计算服务就是这类技术范畴，例如阿里云数据库服务（RDS），阿里云服务器等等。​ 多租户在数据存储上存在三种主要的方案，分别是：1、独立数据库​ 一个租户一个数据库，这种方案的用户数据隔离级别最高，安全性最好，但成本也高。​ 优点：为不同的租户提供独立的数据库，有助于简化数据模型的扩展设计，满足不同租户的独特需求，如果出现故障，恢复数据比较简单。​ 缺点：增大了数据库的安装数量，随之带来维护成本和购置成本的增加2、共享数据库，隔离数据架构​ 多个或者所有租户共享database，但是每一个租户一个schema​ 优点：为安全性要求较高的租户提供了一定程度的逻辑数据隔离，并不是完全隔离；每个数据库可以支持更多的租户数量​ 缺点：如果出现故障，数据恢复比较困难，因此恢复数据库将牵扯到其他租户的数据，如果需要跨租户统计数据，存在一定困难3、共享数据库，共享数据结构​ 租户共享同一个database，同一个schema，但在表中通过tenantID区分租户的数据。这是共享程度最高、隔离级别最低的模式​ 优点：维护和购置成本最低，运行每个数据库支持的租户数量最多​ 缺点：隔离级别最低，安全性最低，需要在设计开发时加大对安全的开发量，数据备份和恢复最困难，需要逐表逐条备份和还原。

RabbitMQ延时队列及消息可靠性 RabbitMQ延时队列及消息可靠性