Combate real de ShardingSphere-jdbc
Prefacio
ShardingSphere-JDBC es el primer producto de Apache ShardingSphere, que pasó a llamarse ShardingSphere. Posicionado como un marco Java liviano, proporciona servicios adicionales en la capa JDBC de Java. Utiliza el cliente para conectarse directamente a la base de datos y proporciona servicios en forma de paquetes jar sin implementación ni dependencias adicionales. Puede entenderse como una versión mejorada del controlador JDBC y es totalmente compatible con JDBC y varios marcos ORM.
Antes de aprender la subbase de datos y la tabla Sharding-JDBC, debemos comprender algunos conocimientos sobre la subbase de datos y la tabla.
Subbase de datos y subtabla
Para una máquina normal (4 núcleos 16G), la concurrencia MySQL (QPS + TPS) de una sola base de datos supera los 2k y el sistema está básicamente terminado. Lo mejor es controlar la concurrencia en alrededor de 1k. Esto lleva a una pregunta: ¿por qué necesitamos dividir bases de datos y tablas?
El propósito de la subbase de datos y la subtabla es resolver los problemas de alta concurrencia y gran volumen de datos.
Hay dos dimensiones para la subbase de datos y la subtabla: vertical y horizontal.
- División horizontal: divida los datos de una base de datos o una tabla en diferentes tablas o diferentes bases de datos según el tiempo, la región o una determinada clave comercial.Después de la división, la estructura de la tabla de cada base de datos es consistente.
- División vertical: divida una tabla grande en varias tablas pequeñas. La estructura de cada tabla de base de datos es diferente, para lograr la división de campos fríos y calientes. También se puede dividir en bases de datos verticales según el negocio, como dividir en bases de datos de usuarios. y ordenar bases de datos. Después de dividir, cada tabla de base de datos solo contiene algunos campos.
Generalmente, las empresas dividirán de acuerdo con el patrón en la figura anterior, primero dividirán verticalmente la base de datos según el negocio y luego dividirán horizontalmente según la base de datos que necesita. para dividirse en tablas.
Idea principal
1. fragmentación
Generalmente, cuando hablamos de partición de bases de datos y tablas, hablamos principalmente en función del modo de fragmentación horizontal (partición de tablas y bases de datos horizontales), y la fragmentación puede entenderse como la división horizontal de bases de datos (tablas). este campo se llama clave de fragmentación. Si no hay un campo de fragmentación en SQL, se realizará un enrutamiento completo y el rendimiento será deficiente.
2. Tabla lógica o tabla real
La tabla lógica no es una tabla real, como una tabla de pedidos, seleccione * del pedido. El orden aquí se refiere a la tabla lógica y no existe. Si dividimos el pedido en orden_1, orden_2 ... orden_n, orden_n es el real Tabla física existente
3. El nodo de datos
es la unidad más pequeña de fragmentación de datos. Consta del nombre de la fuente de datos y la tabla de datos. Por ejemplo, order_db_1.t_order_0 en la figura anterior representa un nodo de datos.
4. Clave primaria distribuida
Después de dividir los datos, es un problema muy difícil para diferentes nodos de datos generar claves primarias únicas globalmente. Las claves de incremento automático entre diferentes tablas reales (t_order_n) en la misma tabla lógica (t_order) no pueden detectarse entre sí. Se generan claves y la fragmentación tiene dos generadores de claves primarias distribuidas integradas, UUID y SNOWFLAKE. De forma predeterminada, el algoritmo de copo de nieve se utiliza para generar datos enteros de 64 bits de largo. No solo eso, también extrae la interfaz del generador de clave primaria distribuida, lo que nos permite implementar un algoritmo personalizado de generación de clave primaria de aumento automático.
5. Estrategia de fragmentación y algoritmo de fragmentación
La estrategia de fragmentación es solo un concepto abstracto: se compone de un algoritmo de fragmentación y una clave de fragmentación, y el algoritmo de fragmentación realiza una lógica de fragmentación de datos específica. Desde la perspectiva de la ejecución de SQL, la fragmentación de bases de datos y tablas puede considerarse como un mecanismo de enrutamiento, que enruta las declaraciones SQL a la base de datos o tabla de datos que esperamos y obtiene datos. El algoritmo de fragmentación puede entenderse como una regla de enrutamiento.
Estrategia de fragmentación:
Estrategia de fragmentación estándar
Solo admite una clave de fragmentación única y puede brindar soporte para operaciones de fragmentación de =, >, <, >=, <=, IN y BETWEEN AND en declaraciones SQL.
Estrategia de fragmentación compleja
Consistente con la fragmentación estándar, pero admite múltiples claves de fragmentación.
Estrategia de fragmentación de expresión de fila (InlineShardingStrategy)
Al utilizar expresiones Groovy, proporciona soporte para operaciones de fragmentación de = e IN en declaraciones SQL. Solo admite la
estrategia de fragmentación Hint de clave de fragmentación única (HintShardingStrategy).
Enrutar por la fuerza a una determinada base de datos y tabla. Esta estrategia no requiere configurar la clave de fragmentación, pero requiere especificar la fragmentación y la información de fragmentación a través del HintManager externo. Algoritmo de fragmentación de estrategia sin fragmentación (NoneShardingStrategy
)
:
Algoritmo de fragmentación preciso
Se utiliza para manejar el escenario de = e IN fragmentación usando una única clave como clave de fragmentación. Debe usarse con StandardShardingStrategy y es un algoritmo requerido para la estrategia estándar.
Algoritmo de fragmentación de rango
Se utiliza para manejar escenarios de fragmentación usando BETWEEN AND, >, <, >=, <= usando una única clave como clave de fragmentación. Debe usarse con StandardShardingStrategy y es un algoritmo opcional para la estrategia estándar.
Algoritmo de fragmentación complejo (ComplexKeysShardingAlgorithm)
Se utiliza para manejar escenarios de fragmentación en los que se utilizan varias claves como claves de fragmentación. La lógica de varias claves de fragmentación es compleja y los desarrolladores de aplicaciones deben manejar la complejidad ellos mismos. Debe usarse con ComplexShardingStrategy.
Algoritmo de fragmentación de sugerencias (HintShardingAlgorithm)
Se utiliza para manejar escenarios en los que se utiliza la fragmentación de filas de sugerencias. Debe usarse con HintShardingStrategy.
Vale la pena señalar que la fragmentación solo proporciona una interfaz para el algoritmo y debemos implementar el algoritmo específico nosotros mismos.
Hay tantas estrategias de fragmentación y algoritmos de fragmentación enumerados que debe estar confundido, echemos un vistazo a algunos casos específicos.
Configuración
Sharding proporciona cuatro métodos de configuración, API de Java, YAML, Spring Boot Starter y espacio de nombres Spring, para diferentes escenarios de uso. A través de la configuración, los desarrolladores de aplicaciones pueden usar de manera flexible funciones como fragmentación de datos, separación de lectura y escritura, cifrado de datos y bibliotecas ocultas, y pueden usarse en combinación.
A continuación probamos a través de YAML y Java API.
Operación práctica de ShardingSphere
1 Crear base de datos
- Primero, cree 4 bibliotecas en navicat, a saber: ds_0, ds_1, ds_2, ds_3;
- En el documento documental, ejecute declaraciones init.sql en cuatro bibliotecas respectivamente. El efecto después de la ejecución se muestra en la figura anterior.
Todavía tomemos la tabla de pedidos como ejemplo: cuando el usuario crea un registro, se generará el siguiente registro:
- Tabla base de pedidos: tabla t_ent_order, 1 registro;
- Tabla de detalles del pedido: t_ent_order_detail, 1 registro;
- Tabla de detalles del pedido: t_ent_order_item, varios registros.
Entonces, ¿qué tipo de estrategia de fragmentación utilizamos?
- La tabla de pedidos básica t_ent_order se divide en bases de datos según ent_id (número de empresa) y la tabla de detalles del pedido permanece coherente;
- La tabla de detalles del pedido t_ent_order_item se divide en bases de datos y tablas según ent_id (número de empresa).
2 Usando shardingsphere jdbc
Primero configure las dependencias:
<!-- shardingsphere jdbc start -->
<dependency>
<groupId>org.apache.shardingsphere</groupId>
<artifactId>sharding-jdbc-spring-boot-starter</artifactId>
<version>4.1.1</version>
</dependency>
<!-- shardingsphere jdbc end -->
Es importante enfatizar que antes de la fragmentación de tablas y bases de datos originales, muchos proyectos Springboot dependían de druid y se deben eliminar las siguientes dependencias:
<dependency>
<groupId>com.alibaba</groupId>
<artifactId>druid-spring-boot-starter</artifactId>
</dependency>
Configure de la siguiente manera en el archivo de configuración:
shardingsphere:
datasource:
enabled: true
names: ds0,ds1,ds2,ds3
ds0:
type: com.alibaba.druid.pool.DruidDataSource
driverClassName: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://127.0.0.1:3306/ds_0?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=GMT%2B8&useTimezone=true
username: root
password: ilxw
ds1:
type: com.alibaba.druid.pool.DruidDataSource
driverClassName: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://127.0.0.1:3306/ds_1?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=GMT%2B8&useTimezone=true
username: root
password: ilxw
ds2:
type: com.alibaba.druid.pool.DruidDataSource
driverClassName: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://127.0.0.1:3306/ds_2?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=GMT%2B8&useTimezone=true
username: root
password: ilxw
ds3:
type: com.alibaba.druid.pool.DruidDataSource
driverClassName: com.mysql.cj.jdbc.Driver
url: jdbc:mysql://127.0.0.1:3306/ds_3?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=GMT%2B8&useTimezone=true
username: root
password: ilxw
props:
# 日志显示 SQL
sql.show: true
sharding:
tables:
# 订单表基础表
t_ent_order:
# 真实表
actualDataNodes: ds$->{0..3}.t_ent_order
# 分库策略
databaseStrategy:
complex:
sharding-columns: id,ent_id
algorithm-class-name: com.courage.shardingsphere.jdbc.service.sharding.HashSlotAlgorithm
# 分表策略
tableStrategy:
none:
# 订单条目表
t_ent_order_item:
# 真实表
actualDataNodes: ds$->{0..3}.t_ent_order_item_$->{0..7}
# 分库策略
databaseStrategy:
complex:
sharding-columns: id,ent_id
algorithm-class-name: com.courage.shardingsphere.jdbc.service.sharding.HashSlotAlgorithm
# 分表策略
tableStrategy:
complex:
sharding-columns: id,ent_id
algorithm-class-name: com.courage.shardingsphere.jdbc.service.sharding.HashSlotAlgorithm
# 订单详情表
t_ent_order_detail:
# 真实表
actualDataNodes: ds$->{0..3}.t_ent_order_detail
# 分库策略
databaseStrategy:
complex:
sharding-columns: id,ent_id
algorithm-class-name: com.courage.shardingsphere.jdbc.service.sharding.HashSlotAlgorithm
# 分表策略
tableStrategy:
complex:
sharding-columns: id,ent_id
algorithm-class-name: com.courage.shardingsphere.jdbc.service.sharding.HashSlotAlgorithm
bindingTables:
- t_ent_order,t_ent_order_detail
La configuración es muy sencilla, es necesario configurar los siguientes puntos:
-
Configurar la fuente de datos. Las fuentes de datos configuradas anteriormente son: ds0, ds1, ds2, ds3;
-
Configure el registro de impresión, es decir: sql.show, que se recomienda activar en el entorno de prueba para facilitar la depuración;
-
Configure qué tablas deben dividirse en bases de datos y tablas, y configúrelas en el nodo shardingsphere.datasource.sharding.tables.
El que está marcado en rojo es el algoritmo de fragmentación de la base de datos, y el siguiente algoritmo de fragmentación de tablas es el mismo.
3 Algoritmo de fragmentación compuesto
Supongamos que la tabla de pedidos ahora debe dividirse uniformemente en cuatro subbases de datos, shard0, shard1, shard2 y shard3. Primero, [0-1023] se divide uniformemente en 4 segmentos: [0-255], [256-511], [512-767], [768-1023], y luego la cadena (o subcadena, determinada por el usuario Personalizado) para realizar hash, el resultado del hash es módulo 1024, y el segmento en el que cae la ranura del resultado final se enrutará a qué subbiblioteca.
El algoritmo de enrutamiento se puede integrar naturalmente con el algoritmo de copo de nieve . El pedido order_id usa el algoritmo de copo de nieve y podemos guardar el valor de la ranura en la ID de la máquina de trabajo de 10 dígitos .
La ranura se puede encontrar a través del pedido order_id y se puede ubicar la partición en la que se almacenan los datos del pedido del usuario.
Integer getWorkerId(Long orderId) { Long workerId = (orderId >> 12) & 0x03ff; return workerId.intValue(); }A continuación, veamos la implementación JAVA del algoritmo de fragmentación, debido a que necesitamos consultar la información del pedido en función de la ID de la clave principal y la ID del usuario, luego debemos implementar la fragmentación compuesta, es decir, implementar la clase ComplexKeysShardingAlgorithm .
Generador de 4 identificaciones
- Consulte la memoria local para determinar si los parámetros currentTime y seq se pueden obtener de la cola local. Si existen, ensamblelos directamente;
- Si no existe, llame al comando INCRBY de redis, aquí debe pasar un valor de paso para facilitar la colocación de un dato en la memoria local;
- Vuelva a escribir datos en la memoria local;
- Vuelva a consultar la memoria local, obtenga los parámetros currentTime y seq de la cola local, ensamble el resultado final y devuélvalo al generador.
Dirección del código fuente: https://github.com/makemyownlife/shardingsphere-jdbc-demo