Я разобрал кое-какую архитектуру Java и материалы интервью (микросервисы, кластеры, распределенное, промежуточное ПО и т.д.), а друзья, кому нужно, могут обратить внимание на официальный аккаунт [Внутренние дела Программиста], и получить самостоятельно без всяких рутин
Автор этой статьи: Изнутри программиста Оригинальная ссылка:Tickets.WeChat.QQ.com/Yes?__Author=M za…
Больше избранного
- Резюме на 30 000 слов, суть оптимизации Mysql
- Чтобы не копировать и не вставлять, я был вынужден изучить краулер JAVA
- Технологический отдел неожиданно объявил, что все JAVA-разработчики должны знать фреймворк автоматизации тестирования интерфейсов.
написать впереди
Два дня назад фанат на официальном аккаунте оставил мне сообщение и пожаловался на недавнее интервью: «Четвертый брат, я уволился голым, когда меня обидели в компании несколько лет назад, и сейчас эпидемия свирепствует уже более два месяца, а я уже больше двух месяцев не могу найти работу.Видеоинтервью нет.Многие интервьюеры задают вопрос, а потом говорят, что есть другие решения?Можете ли вы работать над устранением ошибки? Сколько будет способов?"
Интервьюер должен быть недоволен ответом кандидата, и он хочет услышать решение, которое он считает лучшим, что, собственно, и понятно. Для одной и той же ошибки, человека, который может решить проблему с помощью одной строки кода, или человека, который решает проблему с помощью десяти строк кода, кого бы вы выбрали? Очевидная вещь! Поэтому необходимо смотреть на проблему с нескольких точек зрения, и каждый метод имеет свои преимущества и недостатки.
1. Зачем использовать распределенный идентификатор?
Прежде чем говорить о конкретной реализации распределенного ID, давайте кратко разберем, почему используется распределенный ID? Каким характеристикам должен удовлетворять распределенный идентификатор?
1. Что такое распределенный идентификатор?
Возьмем в качестве примера базу данных MySQL:
Когда объем данных в нашем бизнесе невелик, одна база данных и одна таблица могут полностью поддерживать существующий бизнес.Если данные больше, можно также решить проблему разделения чтения и записи синхронизации MySQL master-slave.
Однако по мере того, как данные растут день ото дня, синхронизация ведущий-ведомый больше не может выполняться, поэтому база данных должна быть подбазой данных и подтаблицей, но после подбазы данных и подтаблицы уникальный идентификатор требуется для идентификации фрагмента данных, а самовозрастающего идентификатора базы данных явно недостаточно.Спрос; специальные элементы, такие как заказы и купоны, также должны иметь唯一IDСделать логотип. В этот момент может генерироваться全局唯一IDсистема очень нужна. тогда это全局唯一IDпросто позвони分布式ID.
2. Каким условиям должен соответствовать распределенный идентификатор?
- Глобально уникальный: идентификатор должен быть глобально уникальным, основные требования
- Высокая производительность: высокая доступность и низкая задержка, ответ на создание идентификатора должен быть заблокирован, иначе он станет узким местом в бизнесе.
- Высокая доступность: 100-процентная доступность обманчива, но она бесконечно близка к 100-процентной доступности.
- Легкий доступ: придерживайтесь принципа готовности к использованию и максимально упростите проектирование и внедрение системы.
- Тенденция роста: лучшая тенденция растет, это требование зависит от конкретного бизнес-сценария, как правило, это не строгие требования.
2. Какие существуют способы создания распределенных идентификаторов?
Сегодня я в основном проанализирую следующие 9 типов методов генератора распределенных идентификаторов, их преимущества и недостатки:
- UUID
- Идентификатор автоинкремента базы данных
- Режим нескольких мастеров базы данных
- Режим сегмента номера
- Redis
- Алгоритм снежинки (SnowFlake)
- Продюсер Диди (TinyID)
- Baidu (генератор удостоверений)
- Мэйтуан (Лист)
Так как же они все реализованы? И каковы преимущества и недостатки каждого? мы смотрим вниз
Вышеуказанные фотографии взяты из Интернета, если есть какие-либо нарушения, пожалуйста, свяжитесь с нами, чтобы удалить
1. На основе UUID
В мире Java, если вы хотите получить уникальный идентификатор, первой мыслью может бытьUUID, в конце концов, у него есть глобально уникальная особенность. ТакUUIDсможет сделать分布式ID?Ответ - да, но не рекомендуется!
public static void main(String[] args) {
String uuid = UUID.randomUUID().toString().replaceAll("-","");
System.out.println(uuid);
}
UUIDГенерация так же проста, как всего одна строка кода, выводящая результатc2b8c2b9e46c47e3b30dca3b0d447718, но UUID не подходит для реальных потребностей бизнеса. как использовать в качестве номера заказаUUIDТакая строка вообще не имеет смысла, и никакой полезной информации, связанной с заказом, не видно, она используется как бизнес для базы данных主键ID, это не только слишком долго или строка, производительность хранилища низкая, а запрос также занимает много времени, поэтому его не рекомендуется использовать分布式ID.
преимущество:
- Генерация достаточно проста, локальная генерация не требует сетевого потребления и уникальна.
недостаток:
- Неупорядоченные строки, не имеющие тенденции к самоувеличению
- Нет конкретных последствий для бизнеса
- Если длина слишком велика, 16 байт, 128 бит и 36-битные строки будут потреблять много ресурсов MySQL для хранения и запросов.MySQL официально рекомендует, чтобы первичный ключ был как можно короче, так как первичный ключ база данных.
UUIDБеспорядок данных приведет к частому изменению местоположения данных, что серьезно повлияет на производительность.
2. На основе идентификатора автоинкремента базы данных
на основе базы данныхauto_incrementСамоувеличивающиеся идентификаторы могут действовать как分布式ID, конкретная реализация: для генерации идентификаторов требуется отдельный экземпляр MySQL, а структура таблицы выглядит следующим образом:
CREATE DATABASE `SEQ_ID`;
CREATE TABLE SEQID.SEQUENCE_ID (
id bigint(20) unsigned NOT NULL auto_increment,
value char(10) NOT NULL default '',
PRIMARY KEY (id),
) ENGINE=MyISAM;
insert into SEQUENCE_ID(value) VALUES ('values');
Когда нам нужен ID, вставляем запись в таблицу и возвращаем主键ID, но у этого метода есть фатальный недостаток: при скачках трафика узким местом системы становится сама MySQL, использовать ее для реализации распределенных сервисов относительно рискованно и не рекомендуется!
преимущество:
- Реализация проста, ID монотонно увеличивается, а скорость запросов числового типа высокая.
недостаток:
- Единая точка БД имеет риск простоя и не может выдерживать сценарии с высокой степенью параллелизма.
3. На основе режима кластера базы данных
Как упоминалось ранее, метод одноточечной базы данных нежелателен, поэтому выполните некоторые оптимизации высокой доступности для вышеуказанного метода и замените его кластером в режиме ведущий-ведомый. Если вы опасаетесь, что одна мастер-нода выйдет из строя, использовать ее будет невозможно, поэтому можно сделать кластер в режиме дуал-мастер, то есть два экземпляра Mysql могут независимо выдавать самоувеличивающиеся идентификаторы.
Тогда будет проблема, ID автоинкремента двух экземпляров MySQL начинается с 1.Что делать, если создаются дубликаты идентификаторов?
решение:настраивать起始值и自增步长
Конфигурация MySQL_1:
set @@auto_increment_offset = 1; -- 起始值
set @@auto_increment_increment = 2; -- 步长
Конфигурация MySQL_2:
set @@auto_increment_offset = 2; -- 起始值
set @@auto_increment_increment = 2; -- 步长
Автоинкрементные идентификаторы двух экземпляров MySQL следующие:
1, 3, 5, 7, 9 2, 4, 6, 8, 10
Что делать, если производительность кластера по-прежнему не справляется с высокой степенью параллелизма? Необходимо расширять мощности MySQL для увеличения узлов, что является хлопотным делом.
Добавить третийMySQLОдин или два экземпляра необходимо изменить вручнуюMySQL实例Начальное значение и размер шага , положить第三台机器的IDНачальная позиция возрождения установлена на более высоком уровне.最大自增IDМесто находится дальше, но это должно быть один или дваMySQL实例ID не вырос до第三台MySQL实例из起始IDзначение, иначе自增IDБудет повтор,Может также потребоваться время простоя для изменения при необходимости.
преимущество:
- Решить проблему с одной точкой БД
недостаток:
- Это не способствует последующему расширению, и на самом деле нагрузка на одну базу данных по-прежнему велика, и она по-прежнему не может соответствовать сценариям с высокой степенью параллелизма.
4. Режим сегмента номера на основе базы данных
Режим числового сегмента является одной из основных реализаций текущего распределенного генератора идентификаторов.Режим числового сегмента можно понимать как получение автоматически увеличивающегося идентификатора в пакетах из базы данных, и каждый раз, когда диапазон числового сегмента берется из базы данных, например (1,1000] представляет 1000. Конкретная бизнес-служба создаст автоматически увеличивающийся идентификатор от 1 до 1000 и загрузит его в память для этого сегмента номера. Структура таблицы выглядит следующим образом:
CREATE TABLE id_generator (
id int(10) NOT NULL,
max_id bigint(20) NOT NULL COMMENT '当前最大id',
step int(20) NOT NULL COMMENT '号段的布长',
biz_type int(20) NOT NULL COMMENT '业务类型',
version int(20) NOT NULL COMMENT '版本号',
PRIMARY KEY (`id`)
)
biz_type : представляет различные типы бизнеса.
max_id : текущий самый большой доступный идентификатор
step : представляет длину сегмента числа
version : это оптимистичная блокировка, и версия обновляется каждый раз, чтобы обеспечить правильность данных во время параллелизма.
| id | biz_type | max_id | step | version |
|---|---|---|---|---|
| 1 | 101 | 1000 | 2000 | 0 |
Когда идентификатор сегмента номера партии израсходован, снова запросите новый сегмент номера из базы данных.max_idполе сделать это один разupdateдействовать,update max_id= max_id + step, успех обновления указывает на то, что новый сегмент номера был успешно получен, и диапазон нового сегмента номера(max_id ,max_id +step].
update id_generator set max_id = #{max_id+step}, version = version + 1 where version = # {version} and biz_type = XXX
Поскольку несколько сервисных терминалов могут работать одновременно, используется номер версии.versionОптимистическое обновление метода блокировки, это分布式IDМетод генерации не сильно зависит от базы данных, доступ к базе данных осуществляется нечасто, и нагрузка на базу данных намного меньше.
5. На основе режима Redis
RedisЭто также может быть достигнуто, принцип заключается в использованииredisизincrКоманда реализует атомарное автоинкрементирование идентификатора.
127.0.0.1:6379> set seq_id 1 // 初始化自增ID为1
OK
127.0.0.1:6379> incr seq_id // 增加1，并返回递增后的数值
(integer) 2
использоватьredisРеализация должна обратить внимание на проблему постоянства Redis.redisСуществует два метода сохраненияRDBиAOF
-
RDBМоментальный снимок будет делаться регулярно для сохранения, если непрерывное самоувеличение, ноredisЭто не сохраняется во времени, и это приведет к зависанию Redis.После перезапуска Redis будут повторяющиеся идентификаторы. -
AOFбудет сохраняться при каждой команде записи, даже еслиRedisДублирования идентификатора не будет, даже если он зависнет, но из-за специфики команды incr это вызоветRedisПерезагрузка для восстановления данных занимает слишком много времени.
6, на основе алгоритма Snowflake (Снежинка)
Snowflake — это алгоритм генерации идентификаторов, принятый во внутренних распределенных проектах Twitter.После того, как он стал открытым, он получил широкое признание крупных отечественных производителей.Под влиянием этого алгоритма крупные компании последовательно разработали распределенные генераторы со своими характеристиками.
Вышеуказанные фотографии взяты из Интернета, если есть какие-либо нарушения, пожалуйста, свяжитесь с нами, чтобы удалить
SnowflakeСгенерированный идентификатор имеет тип Long, тип Long занимает 8 байт, а каждый байт занимает 8 бит, то есть тип Long занимает 64 бита.
Структура композиции ID снежинки:正数位(1 бит)+时间戳(41 бит)+机器ID(5 бит)+数据中心(5 бит)+自增值(занимает 12 бит), тип Long, состоящий всего из 64 бит.
- Первый бит (1 бит): старший бит long в Java — это бит знака, который представляет положительные и отрицательные значения, положительные числа равны 0, а отрицательные числа равны 1. Как правило, сгенерированные идентификаторы являются положительными числами, поэтому по умолчанию используется значение 0. .
- Часть временной метки (41 бит): миллисекундное время, не рекомендуется сохранять текущую временную метку, но разница между (текущая временная метка - фиксированная начальная временная метка) может привести к тому, что сгенерированный идентификатор будет начинаться с меньшего значения; 41 бит. 69 лет, (1л
- Идентификатор рабочей машины (10 бит): также называется
workId, это можно гибко настроить, и можно использовать комбинацию машинного зала или номера машины. - Часть серийного номера (12 бит), самоинкремент поддерживает тот же узел, может генерировать 4096 идентификаторов в течение одной миллисекунды
Согласно логике этого алгоритма, необходимо только реализовать алгоритм на языке Java и инкапсулировать его как инструментальный метод, после чего каждое бизнес-приложение может напрямую использовать инструментальный метод для получения распределенного идентификатора, и нужно только убедиться, что каждый бизнес-приложение имеет свою работу, достаточно id машины, и нет необходимости отдельно создавать приложение для получения распределенного id.
Java-версияSnowflakeРеализация алгоритма:
/**
* Twitter的SnowFlake算法,使用SnowFlake算法生成一个整数，然后转化为62进制变成一个短地址URL
*
* https://github.com/beyondfengyu/SnowFlake
*/
public class SnowFlakeShortUrl {
/**
* 起始的时间戳
*/
private final static long START_TIMESTAMP = 1480166465631L;
/**
* 每一部分占用的位数
*/
private final static long SEQUENCE_BIT = 12; //序列号占用的位数
private final static long MACHINE_BIT = 5; //机器标识占用的位数
private final static long DATA_CENTER_BIT = 5; //数据中心占用的位数
/**
* 每一部分的最大值
*/
private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);
private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);
private final static long MAX_DATA_CENTER_NUM = -1L ^ (-1L << DATA_CENTER_BIT);
/**
* 每一部分向左的位移
*/
private final static long MACHINE_LEFT = SEQUENCE_BIT;
private final static long DATA_CENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;
private final static long TIMESTAMP_LEFT = DATA_CENTER_LEFT + DATA_CENTER_BIT;
private long dataCenterId; //数据中心
private long machineId; //机器标识
private long sequence = 0L; //序列号
private long lastTimeStamp = -1L; //上一次时间戳
private long getNextMill() {
long mill = getNewTimeStamp();
while (mill <= lastTimeStamp) {
mill = getNewTimeStamp();
}
return mill;
}
private long getNewTimeStamp() {
return System.currentTimeMillis();
}
/**
* 根据指定的数据中心ID和机器标志ID生成指定的序列号
*
* @param dataCenterId 数据中心ID
* @param machineId 机器标志ID
*/
public SnowFlakeShortUrl(long dataCenterId, long machineId) {
if (dataCenterId > MAX_DATA_CENTER_NUM || dataCenterId < 0) {
throw new IllegalArgumentException("DtaCenterId can't be greater than MAX_DATA_CENTER_NUM or less than 0！");
}
if (machineId > MAX_MACHINE_NUM || machineId < 0) {
throw new IllegalArgumentException("MachineId can't be greater than MAX_MACHINE_NUM or less than 0！");
}
this.dataCenterId = dataCenterId;
this.machineId = machineId;
}
/**
* 产生下一个ID
*
* @return
*/
public synchronized long nextId() {
long currTimeStamp = getNewTimeStamp();
if (currTimeStamp < lastTimeStamp) {
throw new RuntimeException("Clock moved backwards. Refusing to generate id");
}
if (currTimeStamp == lastTimeStamp) {
//相同毫秒内，序列号自增
sequence = (sequence + 1) & MAX_SEQUENCE;
//同一毫秒的序列数已经达到最大
if (sequence == 0L) {
currTimeStamp = getNextMill();
}
} else {
//不同毫秒内，序列号置为0
sequence = 0L;
}
lastTimeStamp = currTimeStamp;
return (currTimeStamp - START_TIMESTAMP) << TIMESTAMP_LEFT //时间戳部分
| dataCenterId << DATA_CENTER_LEFT //数据中心部分
| machineId << MACHINE_LEFT //机器标识部分
| sequence; //序列号部分
}
public static void main(String[] args) {
SnowFlakeShortUrl snowFlake = new SnowFlakeShortUrl(2, 3);
for (int i = 0; i < (1 << 4); i++) {
//10进制
System.out.println(snowFlake.nextId());
}
}
}
7. Baidu (генератор жидкости)
uid-generatorРазработан отделом технологий Baidu, адрес проекта GitHubGitHub.com/Baidu/UID-a…
uid-generatorоснован наSnowflakeАлгоритмически реализовано, и оригинальноsnowflakeАлгоритм отличается тем,uid-generatorподдержка со стороны定义时间戳,工作机器IDи序列号и так далее по количеству цифр в каждой части, иuid-generatorопределяемые пользователемworkIdстратегия поколения.
uid-generatorЕго нужно использовать вместе с базой данных, и необходимо добавить новый.WORKER_NODEповерхность. Когда приложение запускается, оно вставляет часть данных в таблицу базы данных, а идентификатор автоинкремента, возвращаемый после успешной вставки, является идентификатором машины.workIdДанные состоят из хоста, порта.
заuid-generatorСтруктура композиции ID:
workId, занимает 22 бита, время занимает 28 бит, а сериализация занимает бит 13. Следует отметить, что то же самое, что и исходноеsnowflakeНе то же самое, единица времени секунды, а не миллисекунды,workIdЭто не то же самое, и одно и то же приложение будет потреблять один при каждом перезапуске.workId.
использованная литератураGitHub.com/Baidu/UID-a…
8. Лист
LeafРазработано Meituan, адрес github:GitHub.com/Mehtuan-DI Ах…
LeafПоддерживает как режим числового сегмента, так иsnowflakeАлгоритмический режим, который можно переключить на использование.
Режим сегмента номера
Сначала импортируйте исходный кодGitHub.com/Mehtuan-DI Ах…, строит столleaf_alloc
DROP TABLE IF EXISTS `leaf_alloc`;
CREATE TABLE `leaf_alloc` (
`biz_tag` varchar(128) NOT NULL DEFAULT '' COMMENT '业务key',
`max_id` bigint(20) NOT NULL DEFAULT '1' COMMENT '当前已经分配了的最大id',
`step` int(11) NOT NULL COMMENT '初始步长，也是动态调整的最小步长',
`description` varchar(256) DEFAULT NULL COMMENT '业务key的描述',
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '数据库维护的更新时间',
PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB;
Затем откройте его в проекте号段模式, настройте соответствующую информацию базы данных и закройтеsnowflakeмодель
leaf.name=com.sankuai.leaf.opensource.test
leaf.segment.enable=true
leaf.jdbc.url=jdbc:mysql://localhost:3306/leaf_test?useUnicode=true&characterEncoding=utf8&characterSetResults=utf8
leaf.jdbc.username=root
leaf.jdbc.password=root
leaf.snowflake.enable=false
#leaf.snowflake.zk.address=
#leaf.snowflake.port=
запускатьleaf-serverмодульныйLeafServerApplicationПроект запущен
Режим числового сегмента получает тестовый URL-адрес распределенного самоувеличивающегося идентификатора: http://localhost:8080/API/сегмент/получить/лист-сегмент-тест
Режим сегмента контрольного номера:http://localhost:8080/cache
режим снежинки
LeafРежим снежинки зависит отZooKeeper, отличается от原始snowflakeАлгоритм также в основном вworkIdпо созданиюLeafсерединаworkIdоснован наZooKeeperгенерируется последовательными идентификаторами, которые использует каждое приложениеLeaf-snowflake, оба при запускеZookeeperИдентификатор последовательности генерируется в , что эквивалентно машине, соответствующей узлу последовательности, то естьworkId.
leaf.snowflake.enable=true
leaf.snowflake.zk.address=127.0.0.1
leaf.snowflake.port=2181
Режим Snowflake получает тестовый URL-адрес распределенного самоувеличивающегося идентификатора:http://localhost:8080/api/snowflake/get/test
9. Тиньид
TinyidРазработано Didi, адрес Github:GitHub.com/brother/body должен…
TinyidОн основан на принципе режима сегмента числа и реализуется с помощьюLeafТочно так же каждому сервису присваивается сегмент номера (1000,2000], (2000,3000], (3000,4000]).
Tinyidпоставкаhttpиtinyid-clientДоступ двумя способами
HTTP-доступ
(1) Импортируйте исходный код Tinyid:
git clone GitHub.com/brother/body должен…
(2) Создайте таблицу данных:
CREATE TABLE `tiny_id_info` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增主键',
`biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT '业务类型，唯一',
`begin_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '开始id，仅记录初始值，无其他含义。初始化时begin_id和max_id应相同',
`max_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '当前最大id',
`step` int(11) DEFAULT '0' COMMENT '步长',
`delta` int(11) NOT NULL DEFAULT '1' COMMENT '每次id增量',
`remainder` int(11) NOT NULL DEFAULT '0' COMMENT '余数',
`create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '创建时间',
`update_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新时间',
`version` bigint(20) NOT NULL DEFAULT '0' COMMENT '版本号',
PRIMARY KEY (`id`),
UNIQUE KEY `uniq_biz_type` (`biz_type`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT 'id信息表';
CREATE TABLE `tiny_id_token` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增id',
`token` varchar(255) NOT NULL DEFAULT '' COMMENT 'token',
`biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT '此token可访问的业务类型标识',
`remark` varchar(255) NOT NULL DEFAULT '' COMMENT '备注',
`create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '创建时间',
`update_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新时间',
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT 'token信息表';
INSERT INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`)
VALUES
(1, 'test', 1, 1, 100000, 1, 0, '2018-07-21 23:52:58', '2018-07-22 23:19:27', 1);
INSERT INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`)
VALUES
(2, 'test_odd', 1, 1, 100000, 2, 1, '2018-07-21 23:52:58', '2018-07-23 00:39:24', 3);
INSERT INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`)
VALUES
(1, '0f673adf80504e2eaa552f5d791b644c', 'test', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48');
INSERT INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`)
VALUES
(2, '0f673adf80504e2eaa552f5d791b644c', 'test_odd', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48');
(3) Настройте базу данных:
datasource.tinyid.names=primary
datasource.tinyid.primary.driver-class-name=com.mysql.jdbc.Driver
datasource.tinyid.primary.url=jdbc:mysql://ip:port/databaseName?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8
datasource.tinyid.primary.username=root
datasource.tinyid.primary.password=123456
(4) Стартtinyid-serverпост-тест
获取分布式自增ID: http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c'
返回结果: 3
批量获取分布式自增ID:
http://localhost:9999/tinyid/id/nextIdSimple?bizType=test&token=0f673adf80504e2eaa552f5d791b644c&batchSize=10'
返回结果: 4,5,6,7,8,9,10,11,12,13
Доступ к Java-клиенту
Повторить (2) (3) операции метода Http
импортировать зависимости
<dependency>
<groupId>com.xiaoju.uemc.tinyid</groupId>
<artifactId>tinyid-client</artifactId>
<version>${tinyid.version}</version>
</dependency>
конфигурационный файл
tinyid.server =localhost:9999
tinyid.token =0f673adf80504e2eaa552f5d791b644c
test,tinyid.tokenэто данные, предварительно вставленные в таблицу базы данных,testэто особый тип бизнеса,tinyid.tokenУказывает доступные типы бизнеса
// 获取单个分布式自增ID
Long id = TinyId . nextId( " test " );
// 按需批量分布式自增ID
List< Long > ids = TinyId . nextId( " test " , 10 );
Суммировать
Эта статья лишь кратко представляет каждый генератор распределенных идентификаторов, чтобы дать вам подробное направление обучения.Каждый метод генерации имеет свои преимущества и недостатки, и то, как его использовать, зависит от конкретных потребностей бизнеса.
Сегодня так много нужно сказать, если эта статья была вам полезна, я надеюсь получить от вас лайк 👍
Ваше одобрение является движущей силой для моего письма!