В этой статье рассматриваются три кластерных режима репликации Redis master-slave, Sentinel и Cluster.

Redis

В среде разработки и тестирования мы обычно создаем один экземпляр Redis для удовлетворения требований разработки и тестирования, но в производственной среде, если требования к доступности и надежности высоки, необходимо внедрить кластерное решение Redis. Хотя основные облачные платформы теперь предоставляют услуги кэширования, которые можно использовать напрямую, все же необходимо понимать реализацию и принципы, лежащие в их основе (например, интервью).В этой статье мы узнаем о нескольких кластерных решениях Redis.

Redis поддерживает три схемы кластеризации

  • Режим репликации master-slave
  • Режим стража
  • Кластерный режим

Режим репликации master-slave

1. Основные принципы

Режим репликации master-slave включает экземпляр главной базы данных (master) и один или несколько экземпляров подчиненной базы данных (slave), как показано на следующем рисунке.

redis-master-slave

Клиент может выполнять операции чтения и записи в основной базе данных и операции чтения в подчиненной базе данных, а данные, записанные главной базой данных, будут автоматически синхронизированы с подчиненной базой данных в режиме реального времени.

Конкретный рабочий механизм:

  1. После запуска слейв отправляет мастеру команду SYNC.Получив команду SYNC, мастер сохраняет снимок через bgsave (то есть персистентность RDB, описанную выше), и использует запись буфера для сохранения выполненных команд записи в период съемки.
  2. Ведущее устройство отправляет сохраненный файл моментального снимка подчиненному устройству и продолжает записывать выполненные команды записи.
  3. После того, как ведомое устройство получает файл моментального снимка, оно загружает файл моментального снимка и загружает данные.
  4. После того, как мастер снэпшот отправлен, он начинает посылать команду записи в буфер слейву, а слейв получает команду и выполняет ее, завершая инициализацию репликации
  5. После этого каждый раз, когда мастер выполняет команду записи, она будет синхронно отправляться ведомому для поддержания согласованности данных между ведущим и ведомым.

2. Пример развертывания

Этот пример основан на Redis версии 5.0.3.

Основная конфигурация redis.conf

###网络相关###
# bind 127.0.0.1 # 绑定监听的网卡IP，注释掉或配置成0.0.0.0可使任意IP均可访问
protected-mode no # 关闭保护模式，使用密码访问
port 6379  # 设置监听端口，建议生产环境均使用自定义端口
timeout 30 # 客户端连接空闲多久后断开连接，单位秒，0表示禁用

###通用配置###
daemonize yes # 在后台运行
pidfile /var/run/redis_6379.pid  # pid进程文件名
logfile /usr/local/redis/logs/redis.log # 日志文件的位置

###RDB持久化配置###
save 900 1 # 900s内至少一次写操作则执行bgsave进行RDB持久化
save 300 10
save 60 10000 
# 如果禁用RDB持久化，可在这里添加 save ""
rdbcompression yes #是否对RDB文件进行压缩，建议设置为no，以（磁盘）空间换（CPU）时间
dbfilename dump.rdb # RDB文件名称
dir /usr/local/redis/datas # RDB文件保存路径，AOF文件也保存在这里

###AOF配置###
appendonly yes # 默认值是no，表示不使用AOF增量持久化的方式，使用RDB全量持久化的方式
appendfsync everysec # 可选值 always， everysec，no，建议设置为everysec

###设置密码###
requirepass 123456 # 设置复杂一点的密码

Для развёртывания режима репликации master-slave нужно лишь немного подкорректировать конфигурацию slave, добавить в redis.conf

replicaof 127.0.0.1 6379 # master的ip，port
masterauth 123456 # master的密码
replica-serve-stale-data no # 如果slave无法与master同步，设置成slave不可读，方便监控脚本发现问题

В этом примере настраивается главный порт 6379 на одном сервере, два подчиненных порта — 7001, 7002, запускается главный, а затем запускаются два подчиненных.

[root@dev-server-1 master-slave]# redis-server master.conf
[root@dev-server-1 master-slave]# redis-server slave1.conf
[root@dev-server-1 master-slave]# redis-server slave2.conf

Войдите в основную базу данных, запишите данные, а затем войдите в подчиненную базу данных, вы можете сразу получить доступ к данным, только что записанным в основную базу данных. Следующее

[root@dev-server-1 master-slave]# redis-cli 
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> set site blog.jboost
OK
127.0.0.1:6379> get site
"blog.jboost"
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=7001,state=online,offset=13364738,lag=1
slave1:ip=127.0.0.1,port=7002,state=online,offset=13364738,lag=0
...
127.0.0.1:6379> exit

[root@dev-server-1 master-slave]# redis-cli -p 7001
127.0.0.1:7001> auth 123456
OK
127.0.0.1:7001> get site
"blog.jboost"

воплощать в жизньinfo replicationКоманда может просматривать информацию о других библиотеках, подключенных к базе данных.Как вы можете видеть выше, к мастеру подключены два подчиненных устройства.

3. Преимущества и недостатки репликации master-slave

преимущество:

  1. Мастер может автоматически синхронизировать данные с ведомым, может разделять чтение и запись и разделять давление чтения ведущего.
  2. Синхронизация между ведущим и подчиненным выполняется неблокирующим образом.Во время синхронизации клиенты могут по-прежнему отправлять запросы или запросы на обновление.

недостаток:

  1. Без функций автоматической отказоустойчивости и восстановления время простоя ведущего или ведомого может привести к сбою клиентских запросов, и необходимо дождаться перезагрузки машины или вручную переключить IP-адрес клиента для восстановления.
  2. Если мастер не работает, если данные не синхронизированы до простоя, после переключения IP будут несоответствия данных.
  3. Сложно поддерживать онлайн-расширение, а возможности Redis ограничены конфигурацией с одним компьютером.

Режим стража

1. Основные принципы

Режим Sentinel основан на режиме репликации master-slave, но Sentinel введен для мониторинга и автоматической обработки сбоев. Как показано

redis-sentinel

Sentinels, как следует из названия, должны стоять на страже кластера Redis.Как только обнаружены проблемы, они могут решить их соответствующим образом. Его особенности включают

  1. Контролируйте, нормально ли работают ведущий и ведомый
  2. Когда мастер выходит из строя, он может автоматически преобразовать ведомого в мастера (старший брат вешает трубку, выбирает младшего брата, чтобы занять верхнюю позицию)
  3. Несколько дозорных могут отслеживать один и тот же Redis, и дозорные также будут автоматически отслеживать

Конкретный механизм работы дозорного режима:

передать в файле конфигурацииsentinel monitor <master-name> <ip> <redis-port> <quorum>Чтобы найти IP-адрес и порт мастера, часовой может отслеживать несколько основных баз данных, и ему нужно только предоставить несколько элементов конфигурации. После того, как часовой будет запущен, он установит два соединения с мастером, за которым нужно следить:

  1. Соединение, используемое для подписки на мастер_sentinel_:helloКанал и получение информации о других дозорных узлах, контролирующих мастер
  2. Другое соединение периодически отправляет мастеру INFO и другие команды для получения информации о самом мастере.

После установления соединения с мастером дозорный выполняет три действия:

  1. Периодически (обычно раз в 10 с, когда ведущий помечен как субъективно отключенный, изменить на один раз в 1 с) для отправки команд INFO ведущему и ведомому.
  2. Периодически отчитываться перед ведущим и подчиненным_sentinel_:helloКанал отправляет собственное сообщение
  3. Периодически (раз в 1с) посылать команды PING мастеру, слейву и другим часовым

Отправьте команду INFO, чтобы получить соответствующую информацию о текущей базе данных, чтобы реализовать автоматическое обнаружение новых узлов. Таким образом, сигнальному устройству необходимо только настроить информацию о главной базе данных, чтобы автоматически обнаруживать информацию о подчиненной базе данных. После получения информации о ведомом устройстве Sentinel также установит два соединения с ведомым устройством для осуществления мониторинга. С помощью команды INFO дозорный может получить самую свежую информацию из базы данных master-slave и выполнить соответствующие операции, такие как изменение ролей.

Затем дозорный отправляет информацию в канал _sentinel_:hello базы данных master-slave и делится своей информацией с дозорными, которые также отслеживают эти базы данных. IP-порт мастера и многое другое Версия конфигурации мастера. Эта информация полезна для:

  1. Другие дозорные могут использовать эту информацию, чтобы определить, является ли отправитель недавно обнаруженным дозорным, и если это так, создать соединение с дозорным для отправки команд PING.
  2. Другие часовые могут судить о версии мастера по этой информации.Если версия выше, чем непосредственно записанная версия, она будет обновлена.
  3. После автоматического обнаружения подчиненных и других контрольных узлов дозорный может регулярно отслеживать, остановили ли эти базы данных и узлы службы, регулярно отправляя команды PING.

Если пропингованная база данных или узел истекли (черезsentinel down-after-milliseconds master-name millisecondsConfiguration) не ответил, а дозорный посчитал его субъективно офлайновым (sdown, s is Subjectively - субъективно). Если мастер находится в автономном режиме, дозорный отправит команду другим часовым, чтобы спросить, считают ли они, что мастер субъективно отключен.Если достигнуто определенное количество голосов (то есть кворум в файле конфигурации), дозорный будет думать, что ведущий был объективно отключен (odown). , o is Objectively — объективно), и выбирает ведущий контрольный узел для инициирования восстановления после сбоя в системе ведущий-подчиненный. Если контрольных процессов недостаточно, чтобы позволить главному устройству перейти в автономный режим, объективное автономное состояние главного устройства будет удалено.Если команда PING, отправленная ведущим контрольному процессу, возвращает действительный ответ, субъективное автономное состояние главного устройства будет удален.

Дозор считает, что после того, как мастер объективно отключен, операция восстановления после сбоя должна быть выполнена ведущим дозором выборов.Выборы принимают алгоритм Raft:

  1. Дозорный узел (назовем его А), обнаруживший ведущего в автономном режиме, отправляет команду каждому дозорному, прося другую сторону выбрать себя в качестве ведущего дозорного.
  2. Если целевой дозорный узел не выбрал никого другого, он согласится выбрать A в качестве ведущего дозорного.
  3. А избран, если более половины Стражей согласны избрать А лидером.
  4. Если в выборах одновременно участвует несколько дозорных узлов, может быть раунд голосования без победы кандидата.В это время каждый узел, участвующий в выборах, ждет случайное время, а затем снова инициирует запрос на выборы, и проводит следующий тур голосования до избрания ведущего стража

После того, как лидер-страж выбран, лидер начинает восстанавливать систему после сбоя и выбирает один из базы данных вышедшего из строя мастера для избрания нового мастера.Правила выбора следующие:

  1. Выберите наивысший приоритет среди всех онлайн-ведомых, и приоритет можно настроить с помощью slave-priority.
  2. Если имеется несколько ведомых устройств с наивысшим приоритетом, выбирается тот, у которого наибольшее смещение репликации (то есть более полная репликация).
  3. Если вышеуказанные условия совпадают, выберите ведомое устройство с наименьшим идентификатором.

После выбора ведомого, которому необходимо преуспеть, ведущий дозорный отправляет команду в базу данных, чтобы обновить ее до ведущего, а затем отправляет команды другим ведомым, чтобы они приняли нового ведущего, и, наконец, обновляет данные. Обновите остановленный старый мастер до подчиненной базы данных нового мастера, чтобы он продолжал работать как подчиненный после восстановления службы.

2. Разверните демо

Этот пример основан на Redis версии 5.0.3.

Режим Sentinel основан на предыдущем режиме репликации master-slave. Файл конфигурации Sentinel — sentinel.conf, добавьте в файл

sentinel monitor mymaster 127.0.0.1 6379 1 # mymaster定义一个master数据库的名称，后面是master的ip， port，1表示至少需要一个Sentinel进程同意才能将master判断为失效，如果不满足这个条件，则自动故障转移（failover）不会执行
sentinel auth-pass mymaster 123456 # master的密码

sentinel down-after-milliseconds mymaster 5000 # 5s未回复PING，则认为master主观下线，默认为30s
sentinel parallel-syncs mymaster 2  # 指定在执行故障转移时，最多可以有多少个slave实例在同步新的master实例，在slave实例较多的情况下这个数字越小，同步的时间越长，完成故障转移所需的时间就越长
sentinel failover-timeout mymaster 300000 # 如果在该时间（ms）内未能完成故障转移操作，则认为故障转移失败，生产环境需要根据数据量设置该值

Sentinel может отслеживать несколько основных баз данных, просто добавьте несколько наборов в соответствии с приведенной выше конфигурацией.

Запустите три часовых с портами 26379, 36379, 46379 соответственно.

[root@dev-server-1 sentinel]# redis-server sentinel1.conf --sentinel
[root@dev-server-1 sentinel]# redis-server sentinel2.conf --sentinel
[root@dev-server-1 sentinel]# redis-server sentinel3.conf --sentinel

также можно использоватьredis-sentinel sentinel1.confкоманда запускается. На данный момент кластер содержит один ведущий, два подчиненных и три сигнальных устройства, как показано на рисунке.

redis-cluster-instance

Давайте смоделируем сценарий, когда мастер зависнет и выполнитkill -9 3017Убейте главный процесс и запустите его в ведомомinfo replicationПроверять,

[root@dev-server-1 sentinel]# redis-cli -p 7001
127.0.0.1:7001> auth 123456
OK
127.0.0.1:7001> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:7002
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
# 省略
127.0.0.1:7001> exit
[root@dev-server-1 sentinel]# redis-cli -p 7002
127.0.0.1:7002> auth 123456
OK
127.0.0.1:7002> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=7001,state=online,offset=13642721,lag=1
# 省略

Видно, что ведомое устройство 7002 успешно повышено до ведущего (роль: ведущее устройство) и получает соединение от ведомого устройства 7001. На этом этапе просмотрите файл конфигурации slave2.conf и найдите, чтоreplicaofКонфигурация удалена, в конфигурационном файле slave1.confreplicaof 127.0.0.1 6379был изменен наreplicaof 127.0.0.1 7002. Перезапускаем мастер, так же видно что добавился конфигурационный файл master.confreplicaof 127.0.0.1 7002Видно, что после того, как старший брат (хозяин) находится в положении, он может быть рабом (рабом) только тогда, когда выходит и смешивается, тридцать лет в Хэдуне и тридцать лет в Хэси.

3. Преимущества и недостатки режима Sentinel

преимущество:

  1. Режим Sentinel основан на режиме репликации master-slave, поэтому режим репликации master-slave имеет преимущества, а режим Sentinel также имеет преимущества.
  2. В сторожевом режиме мастер может автоматически переключаться, если зависает, и доступность системы выше

недостаток:

  1. Он также наследует недостаток, заключающийся в том, что режим «ведущий-ведомый» трудно расширять онлайн, а мощность Redis ограничена конфигурацией с одним компьютером.
  2. Для запуска дозорного процесса требуются дополнительные ресурсы, реализация относительно сложна, а подчиненный узел не предоставляет услуги в качестве резервного узла.

Кластерный режим

1. Основные принципы

Режим Sentinel решает проблему, заключающуюся в том, что репликация master-slave не может автоматически переключаться при сбое и не может обеспечить высокую доступность, но по-прежнему существует проблема, заключающаяся в том, что онлайн-расширение затруднено, а емкость Redis ограничена конфигурацией с одним компьютером. Режим Cluster реализует распределенное хранилище Redis, то есть каждый узел хранит разный контент для решения проблемы онлайн-экспансии. Как показано

redis-cluster

Кластер имеет бесцентровую структуру и имеет следующие характеристики:

  1. Все узлы redis взаимосвязаны друг с другом (механизм PING-PONG), а внутренний бинарный протокол используется для оптимизации скорости передачи и пропускной способности.
  2. Сбой узла вступает в силу только тогда, когда более половины узлов в кластере обнаруживают сбой.
  3. Клиент напрямую подключается к узлу redis и не требует промежуточного уровня прокси.Клиенту не нужно подключаться ко всем узлам в кластере, достаточно подключиться к любому доступному узлу в кластере.

Конкретный рабочий механизм режима кластера:

  1. На каждой ноде Redis есть слот (slot), диапазон значений 0-16383
  2. Когда мы получим доступ к ключу, Redis получит результат в соответствии с алгоритмом CRC16, а затем возьмет остаток результата до 16384, так что каждый ключ будет соответствовать хеш-слоту с номером от 0 до 16383, через это значение, чтобы найти узел, соответствующий соответствующему слоту, а затем автоматически перейти непосредственно к соответствующему узлу для операций доступа
  3. Чтобы обеспечить высокую доступность, режим кластера также вводит режим репликации ведущий-ведомый.Главный узел соответствует одному или нескольким подчиненным узлам.Когда главный узел выходит из строя, подчиненный узел включается.
  4. Когда другие главные узлы пингуют главный узел A, если более половины главных узлов взаимодействуют с A сверхурочно, то главный узел A считается отключенным. Если главный узел A и его подчиненные узлы не работают, кластер больше не может предоставлять услуги.

Узлы кластера в режиме кластера конфигурируются как минимум с 6 узлами (3 ведущих и 3 подчиненных, поскольку требуется более половины из них), из которых главный узел обеспечивает операции чтения и записи, а подчиненный узел действует как резервный узел, который не предоставляет запросы и используется только для отработки отказа.

2. Разверните демо

Этот пример основан на Redis версии 5.0.3.

Развертывание режима кластера относительно простое, сначала в redis.conf.

port 7100 # 本示例6个节点端口分别为7100,7200,7300,7400,7500,7600 
daemonize yes # r后台运行 
pidfile /var/run/redis_7100.pid # pidfile文件对应7100,7200,7300,7400,7500,7600 
cluster-enabled yes # 开启集群模式 
masterauth passw0rd # 如果设置了密码，需要指定master密码
cluster-config-file nodes_7100.conf # 集群的配置文件，同样对应7100,7200等六个节点
cluster-node-timeout 15000 # 请求超时 默认15秒，可自行设置

Запустите шесть инстансов с портами 7100, 7200, 7300, 7400, 7500, 7600 соответственно (если это один инстанс на сервер, конфигурация может быть одинаковой)

[root@dev-server-1 cluster]# redis-server redis_7100.conf
[root@dev-server-1 cluster]# redis-server redis_7200.conf
...

Затем сделайте это 6 экземплярами в кластер узла через команду.

redis-cli --cluster create --cluster-replicas 1 127.0.0.1:7100 127.0.0.1:7200 127.0.0.1:7300 127.0.0.1:7400 127.0.0.1:7500 127.0.0.1:7600 -a passw0rd

Результат выполнения показан на рисунке

redis-cluster-deploy

Видно, что 7100, 7200 и 7300 используются как 3 главных узла, а выделенные слоты 0-5460, 5461-10922, 10923-16383, 7600 — подчиненный узел 7100, 7500 — подчиненный узел 7300, и 7400 - раб 7200.

Подключаем 7100 для установки значения

[root@dev-server-1 cluster]# redis-cli -p 7100 -c -a passw0rd
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:7100> set site blog.jboost
-> Redirected to slot [9421] located at 127.0.0.1:7200
OK
127.0.0.1:7200> get site
"blog.jboost"
127.0.0.1:7200>

Обратите внимание, что добавление параметра -c указывает на то, что он находится в режиме кластера, в противном случае он сообщает(error) MOVED 9421 127.0.0.1:7200Ошибка, укажите пароль с параметром -a, иначе сообщите(error) NOAUTH Authentication requiredОшибка.

Из приведенной выше команды мы видим, что слот, рассчитанный по ключу как сайт, равен 9421, который приходится на узел 7200, поэтому естьRedirected to slot [9421] located at 127.0.0.1:7200, кластер автоматически перепрыгнет. Таким образом, клиент может подключиться к любому узлу для доступа к данным.

пройти черезcluster nodesВы можете просмотреть информацию об узле кластера

127.0.0.1:7200> cluster nodes
eb28aaf090ed1b6b05033335e3d90a202b422d6c 127.0.0.1:7500@17500 slave c1047de2a1b5d5fa4666d554376ca8960895a955 0 1584165266071 5 connected
4cc0463878ae00e5dcf0b36c4345182e021932bc 127.0.0.1:7400@17400 slave 5544aa5ff20f14c4c3665476de6e537d76316b4a 0 1584165267074 4 connected
dbbb6420d64db22f35a9b6fa460b0878c172a2fb 127.0.0.1:7100@17100 master - 0 1584165266000 1 connected 0-5460
d4b434f5829e73e7e779147e905eea6247ffa5a2 127.0.0.1:7600@17600 slave dbbb6420d64db22f35a9b6fa460b0878c172a2fb 0 1584165265000 6 connected
5544aa5ff20f14c4c3665476de6e537d76316b4a 127.0.0.1:7200@17200 myself,master - 0 1584165267000 2 connected 5461-10922
c1047de2a1b5d5fa4666d554376ca8960895a955 127.0.0.1:7300@17300 master - 0 1584165268076 3 connected 10923-16383

Мы проедем 7200kill -9 pidЗавершите процесс, чтобы проверить высокую доступность кластера, и повторно войдите в кластер для выполнения.cluster nodesВы можете видеть, что 7200 вышел из строя, но 7400 стал ведущим, перезапустите 7200, вы можете видеть, что в это время 7200 стал ведомым.

3. Преимущества и недостатки режима кластера

преимущество:

  1. Нет центральной архитектуры, и данные распределяются по нескольким узлам в соответствии со слотом.
  2. Каждый узел в кластере представляет собой отношение равенства, и каждый узел содержит свои данные и состояние всего кластера. Каждый узел подключен ко всем другим узлам, и эти соединения остаются активными, что гарантирует, что нам нужно только подключиться к любому узлу в кластере, чтобы получить данные с других узлов.
  3. Линейное масштабирование до более чем 1000 узлов, узлы можно динамически добавлять или удалять.
  4. Он может реализовать автоматическое переключение при сбое, обмениваться информацией о состоянии между узлами через протокол сплетен и использовать механизм голосования для завершения преобразования роли из ведомого в ведущее.

недостаток:

  1. Реализация клиента сложна, и драйвер требует реализации Smart Client для кэширования информации о сопоставлении слотов и ее своевременного обновления, что усложняет разработку. В настоящее время только JedisCluster является относительно зрелым, и обработка исключений не идеальна, например, обычное «исключение максимального перенаправления».
  2. Узел будет заблокирован по какой-то причине (время блокировки больше, чем время ожидания кластера-узла) и будет оцениваться как автономный.
  3. Данные реплицируются асинхронно, и строгая согласованность данных не гарантируется.
  4. Подчиненное устройство действует как «холодный резерв» и не может уменьшить давление чтения.
  5. Ограничение пакетной операции.В настоящее время для выполнения пакетных операций поддерживаются только ключи с одинаковым значением слота, что несовместимо с такими операциями, как mset, mget и sunion.
  6. Операция транзакции с ключом поддерживает проводную связь и поддерживает только операцию транзакции с несколькими ключами на одном узле.Функция транзакции не может использоваться, когда несколько ключей распределены по разным узлам.
  7. Несколько пространств базы данных не поддерживаются. Redis на одном компьютере может поддерживать 16 баз данных. В режиме кластера можно использовать только одно, а именно базу данных 0.

В режиме кластера Redis не рекомендуется использовать конвейерные операции и операции с несколькими ключами, чтобы уменьшить количество сценариев, вызванных максимальным перенаправлением.

Суммировать

В этой статье представлены три режима схемы кластеризации Redis.Среди них: режим репликации ведущий-ведомый может реализовать разделение чтения-записи, но не может автоматически выполнять отработку отказа; режим дозорного основан на режиме репликации ведущий-ведомый, который может обеспечить автоматическое переключение при отказе. и достичь высокой доступности, но он отличается от режима ведущий-ведомый.Как и в режиме репликации, емкость не может быть расширена в режиме онлайн, и емкость ограничена конфигурацией одной машины, режим кластера реализует распределенное хранилище через децентрализованную архитектура, которая может быть линейно расширена и высокодоступна, но поддерживает пакетные операции, операции транзакций и т. д. Секса недостаточно. Три режима имеют свои преимущества и недостатки, и их можно выбирать в соответствии с реальной сценой.

Ссылаться на:

  1. blog.CSDN.net/пожалуйста 649381130/…
  2. блог woo woo woo.cn на.com/51life/afraid/10…
  3. Блог Woohoo.cn на.com/Chen Suqian/…
  4. Да Tor.51CTO.com/art/201910/…

Автор: Конгшан Синьюй, пожилой фермер-кодировщик, который все еще учится.
За последнее время автор написал десятки технических блогов, включая Java, Spring Boot, Spring Cloud, Docker, опыт технического управления и т. д.
Добро пожаловать, чтобы обратить внимание на публичный аккаунт автора WeChat: техническое пространство Kongshan Xinyu, учиться и расти вместе

微信公众号

Категории