Проблемы MySQL параллельно, решающие идеи

база данных MySQL
Код меняет мир

летящий красный шарф

Проблемы и решения MySQL в параллельных сценариях

2018-01-15 08:29 от flying red scarf, 4974 чтения, 13 комментариев,собирать, редактировать

содержание

1. Предпосылки

2. Проблема медленных запросов из-за блокировок таблиц

3. Каковы риски изменения структуры таблицы онлайн?

4. Анализ проблемы взаимоблокировки

5. Анализ проблемы ожидания блокировки

6. Резюме

1. Предпосылки

Для систем баз данных улучшение параллелизма в условиях многопользовательского параллелизма и обеспечение согласованности данных всегда было целью, которую преследовали системы баз данных.Это необходимо для удовлетворения потребностей большого количества одновременных обращений и обеспечения безопасности данных при этом условии. Для достижения этой цели в большинстве баз данных реализованы механизмы блокировки и транзакций, и базы данных MySQL не являются исключением. Несмотря на это, в процессе развития бизнеса мы все равно будем сталкиваться с различными сложными проблемами, в этой статье мы продемонстрируем распространенные проблемы параллелизма и разберем решения в виде кейсов.

2. Проблема медленных запросов из-за блокировок таблиц

Во-первых, давайте рассмотрим простой случай, запросим информацию о пользователе на основе идентификатора:

mysql> select * from user where id=6;

Общее количество записей в этой таблице равно 3, но выполнение заняло 13 секунд.

Когда возникает эта проблема, наша первая мысль — посмотреть на текущий статус процесса MySQL:

Из процесса видно, что оператор select ожидает блокировку таблицы, так какой же запрос генерирует эту блокировку таблицы? Этот результат не показывает прямой связи, но мы можем предположить, что большая его часть генерируется оператором обновления (поскольку в процессе нет другого подозрительного SQL).Чтобы подтвердить наше предположение, сначала проверьте структуру пользовательской таблицы:

Конечно же, пользовательская таблица использует механизм хранения MyISAM, MyISAM создаст блокировку таблицы перед выполнением операции и автоматически разблокирует ее после завершения операции. Если операция является операцией записи, тип блокировки таблицы — блокировка записи, а если операция — операция чтения, тип блокировки таблицы — блокировка чтения. Как вы понимаете, блокировки записи будут блокировать другие операции (включая чтение и запись), что делает все операции последовательными, при блокировках чтения операции чтения-чтения можно распараллелить, но операции чтения-записи все равно будут последовательными. В следующем примере демонстрируется случай, когда блокировка таблицы (блокировка чтения), параллельное чтение-чтение и последовательное чтение-запись указаны явно.

Чтобы явно открывать/закрывать блокировки таблиц, используйте блокировку чтения/записи пользователем таблицы, разблокировку таблиц;

session1:

сеанс2:

Видно, что сессия 1 разрешает блокировки таблицы (блокировки чтения) для выполнения операций чтения, в то время как сессия 2 может выполнять операции чтения параллельно, но операции записи заблокированы. Затем см.:

session1:

session2:

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

Суммировать:

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

Решение:

1) Старайтесь не использовать механизм хранения MyISAM.В MySQL 8.0 все таблицы механизма хранения MyISAM были удалены, и рекомендуется использовать механизм хранения InnoDB.

2) Если вы должны использовать механизм хранения MyISAM, уменьшите время записи;

3. Каковы риски изменения структуры таблицы онлайн?

Если однажды бизнес-системе потребуется увеличить длину поля, можно ли будет изменить его прямо в режиме онлайн? Прежде чем ответить на этот вопрос, давайте рассмотрим случай:

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

Из процесса видно, что оператор alter ожидает блокировки метаданных, и эта блокировка метаданных, вероятно, вызвана приведенным выше оператором select, что как раз и есть. При выполнении операций DML (выбрать, обновить, удалить, вставить) к таблице добавляется блокировка метаданных, которая гарантирует, что структура таблицы не будет изменена во время запроса, поэтому указанный выше оператор alter будет заблокирован. А что, если порядок выполнения будет обратным и сначала будет выполнен оператор alter, а затем оператор DML? Будут ли заблокированы операторы DML? Например, если я изменяю структуру таблицы в онлайн-среде, будет ли заблокирован онлайн-оператор DML? Ответ: не уверен.

В MySQL 5.6 была предоставлена ​​функция интерактивного ddl, позволяющая выполнять некоторые операторы DDL и операторы DML одновременно. Онлайновый ddl был улучшен в текущей версии 5.7, что позволяет выполнять большинство операций DDL в режиме онлайн. Видеть:Dev.MySQL.com/doc/Furious/…

Таким образом, во время выполнения DDL для определенного сценария, будет ли заблокирован DML, зависит от сценария.

Резюме: Благодаря этому примеру у нас есть общее представление о блокировках метаданных и онлайн-ddl.Если нам нужно изменить структуру таблицы онлайн в процессе развития бизнеса, мы можем обратиться к следующим решениям:

1. Старайтесь делать это в период времени с небольшим объемом бизнеса;

2. Проверьте официальные документы и подтвердите, что изменение таблицы, которое должно быть выполнено, может выполняться одновременно с DML и не будет блокировать онлайн-бизнес;

3. Рекомендуется использовать инструмент pt-online-schema-change компании percona, который мощнее официального онлайн-ddl.Его основной принцип: сделать полную копию через оператор insert...select... и запишите структуру таблицы с помощью триггеров. Приращение, созданное в процессе изменения, для достижения цели изменения структуры таблицы.

Например, чтобы внести изменения в таблицу А, необходимо выполнить следующие основные шаги:

Создайте пустую структуру таблицы назначения таблицы, A_new;
Создание триггеров в таблице A, включая добавление, удаление и изменение триггеров;
Скопируйте данные в целевую таблицу по сегментам с помощью операторов insert...select...limit N
После завершения копирования переименуйте таблицу A_new в таблицу A.

4. Анализ проблемы взаимоблокировки

Тупик иногда возникает в онлайн-среде.Взаимоблокировка — это ситуация, в которой две или более транзакций ждут друг друга, чтобы снять блокировки, что приводит к транзакциям, которые никогда не могут быть завершены. Чтобы проанализировать проблему, мы смоделируем ниже простую тупиковую ситуацию, а затем обобщим некоторые идеи анализа.

Демонстрационная среда: MySQL5.7.20 Уровень изоляции транзакций: RR

Пользователь таблиц:

CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(300) DEFAULT NULL,
`age` int(11) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8

Ниже показано, как транзакция 1 и транзакция 2 работы:

  Транзакция 1 Транзакция 2 Мониторинг транзакций
T1

begin;

Query OK, 0 rows affected (0.00 sec)

begin;

Query OK, 0 rows affected (0.00 sec)

 
T2

select * from user where id=3 for update;

+----+------+------+
| id | name | age |
+----+------+------+
| 3 | sun | 20 |
+----+------+------+
1 row in set (0.00 sec)

select * from user where id=4 for update;

+----+------+------+
| id | name | age |
+----+------+------+
| 4 | zhou | 21 |
+----+------+------+
1 row in set (0.00 sec)

выберите * из information_schema.INNODB_TRX;

Запрашивая таблицу транзакций innodb метабазы ​​данных, отслеживается, что количество текущих транзакций равно 2, то есть транзакция 1 и транзакция 2.

T3

update user set name='haha' where id=4;

Поскольку запись с id=4 была заблокирована транзакцией 2, инструкция будет заблокирована.

  Для мониторинга текущего количества транзакций работает 2.
T4 состояние блокировки

update user set name='hehe' where id=3;

ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction

Запись с идентификатором = 3 была заблокирована транзакцией 1, и транзакция удерживает блокировку строки для записи с идентификатором = 4. В это время механизм хранения InnoDB обнаруживает взаимоблокировку, и транзакция откатывается.

Транзакция 2 откатывается, транзакция 1 все еще выполняется, а число отслеживаемых в данный момент транзакций равно 1.
T5

Query OK, 1 row affected (20.91 sec)Rows matched: 1 Changed: 1 Warnings: 0

Поскольку транзакция 2 откатывается, возобновляется исходный блокирующий оператор обновления.

  Количество отслеживаемых в данный момент транзакций равно 1.
T6

совершить;

Query OK, 0 rows affected (0.00 sec)

  Транзакция 1 была совершена, транзакция 2 откатывалась назад, а количество текущих операций выполнения составляет 0.

Это простой сценарий взаимоблокировки. Транзакция 1 и транзакция 2 ждут друг друга, чтобы снять блокировку. Механизм хранения InnoDB обнаруживает взаимоблокировку и откатывает транзакцию 2, что заставляет транзакцию 1 больше не ждать блокировки транзакции B и может продолжить. Так как же механизм хранения InnoDB обнаруживает взаимоблокировки? Чтобы понять эту проблему, мы сначала проверим состояние InnoDB в это время:

show engine innodb status\G

------------------------
LATEST DETECTED DEADLOCK
------------------------
2018-01-14 12:17:13 0x70000f1cc000
*** (1) TRANSACTION:
TRANSACTION 5120, ACTIVE 17 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 10, OS thread handle 123145556967424, query id 2764 localhost root updating
update user set name='haha' where id=4
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 94 page no 3 n bits 80 index PRIMARY of table `test`.`user` trx id 5120 lock_mode X locks rec but not gap waiting
Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000004; asc ;;
1: len 6; hex 0000000013fa; asc ;;
2: len 7; hex 520000060129a6; asc R ) ;;
3: len 4; hex 68616861; asc haha;;
4: len 4; hex 80000015; asc ;;

*** (2) TRANSACTION:
TRANSACTION 5121, ACTIVE 12 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 1136, 2 row lock(s)
MySQL thread id 11, OS thread handle 123145555853312, query id 2765 localhost root updating
update user set name='hehe' where id=3
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 94 page no 3 n bits 80 index PRIMARY of table `test`.`user` trx id 5121 lock_mode X locks rec but not gap
Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000004; asc ;;
1: len 6; hex 0000000013fa; asc ;;
2: len 7; hex 520000060129a6; asc R ) ;;
3: len 4; hex 68616861; asc haha;;
4: len 4; hex 80000015; asc ;;

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 94 page no 3 n bits 80 index PRIMARY of table `test`.`user` trx id 5121 lock_mode X locks rec but not gap waiting
Record lock, heap no 7 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000003; asc ;;
1: len 6; hex 0000000013fe; asc ;;
2: len 7; hex 5500000156012f; asc U V /;;
3: len 4; hex 68656865; asc hehe;;
4: len 4; hex 80000014; asc ;;

*** WE ROLL BACK TRANSACTION (2)

Есть много индикаторов состояния InnoDB.Здесь мы перехватываем информацию, связанную с взаимоблокировками.Видно, что InnoDB может выводить самую последнюю информацию о взаимоблокировках.На самом деле многие инструменты мониторинга взаимоблокировок также разработаны на основе этой функции.

В информации о взаимоблокировке отображается соответствующая информация о двух транзакциях, ожидающих блокировки (синий цвет представляет транзакцию 1, зеленый цвет представляет транзакцию 2), с акцентом на: ОЖИДАНИЕ ПРЕДОСТАВЛЕНИЯ ЭТОЙ БЛОКИРОВКИ и УДЕРЖИВАНИЕ БЛОКИРОВКИ.

WAITING FOR THIS LOCK TO BE GRANTED указывает информацию о блокировке, которую ожидает текущая транзакция.Из вывода видно, что транзакция 1 ожидает блокировки строки с кучей № 5, а транзакция 2 ожидает блокировки строки с кучей № 7;

HOLDS THE LOCK(S): Указывает информацию о блокировке, удерживаемую текущей транзакцией.Из вывода видно, что транзакция 2 содержит кучу блокировок не из 5 строк.

Из вывода можно увидеть, что InnoDB прокатал обратно транзакцию 2 в конце.

Так как же InnoDB проверяет взаимоблокировки?

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

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

Ниже приведен основной принцип алгоритма графа ожидания:

Для простоты понимания давайте подумаем о тупике как о сценарии, в котором 4 машины блокируют друг друга:

                

4 машины рассматриваются как 4 транзакции, каждая из которых ожидает блокировки друг друга, что приводит к взаимоблокировке. Принцип алгоритма графа ожидания заключается в использовании транзакций в качестве узлов, а отношение ожидания блокировки между транзакциями представлено направленными ребрами.Например, когда транзакция A ожидает блокировки транзакции B, направленное ребро рисуется из узла A к узлу B, так что если ориентированный граф, состоящий из A, B, C и D, образует цикл, он оценивается как тупик. Это основной принцип алгоритма ожидания графа.

Суммировать:

1. Как проверить, нет ли тупика в развитии нашего бизнеса? Было введено, что, отслеживая состояние InnoDB, вы можете сделать небольшой инструмент для сбора записей взаимоблокировок для последующего просмотра.

2. Если возникает тупик, как должна реагировать бизнес-система? Из вышеприведенного мы видим, что когда InnoDB обнаруживает взаимоблокировку, она сообщает об обнаружении взаимоблокировки при попытке получить блокировку; попробуйте перезапустить информацию о транзакции для клиента и откатить транзакцию.Приложению необходимо перезапустить транзакцию на основе этой информации. .и сохраните локальный журнал для дальнейшего анализа, чтобы избежать возникновения следующей взаимоблокировки.

5. Анализ проблемы ожидания блокировки

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

  Транзакция 1 Транзакция 2 Мониторинг транзакций
T1

begin;

Query OK, 0 rows affected (0.00 sec)

begin;

Query OK, 0 rows affected (0.00 sec)

 
T2

select * from user where id=3 for update;

+----+------+------+
| id | name | age |
+----+------+------+
| 3 | sun | 20 |
+----+------+------+
1 row in set (0.00 sec)

Другие операции запроса

выберите * из information_schema.INNODB_TRX;

Запрашивая таблицу транзакций innodb метабазы ​​данных, отслеживается, что количество текущих транзакций равно 2, то есть транзакция 1 и транзакция 2.

T3 Другие операции запроса

 update user set name='hehe' where id=3;

Поскольку запись с id=3 заблокирована транзакцией 1, инструкция будет заблокирована (т.е. ожидание блокировки)

Количество текущих транзакций отслеживается до 2.
T4 Другие операции запроса

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

Время ожидания блокировки превышает пороговое значение, и операция завершается ошибкой. Примечание. В этот момент транзакция 2 не откатывается.

Количество текущих транзакций отслеживается до 2.
T5 commit;   Транзакция 1 была зафиксирована, но транзакция 2 не была зафиксирована, и количество текущих транзакций равно 1.

Из вышеизложенного видно, что транзакция 1 длительное время удерживает блокировку строки с id=3, а транзакция 2 генерирует ожидание блокировки, после того как время ожидания превышает innodb_lock_wait_timeout, операция прерывается, но откат транзакции не происходит. Если мы столкнемся с ожиданием блокировки в развитии бизнеса, это не только повлияет на производительность, но и вызовет трудности для вашего бизнес-процесса, потому что ваша бизнес-сторона должна адаптировать логику к ситуации ожидания блокировки, будь то повторная попытка операции или откат транзакции.

Информация о транзакциях и ожидании блокировки собирается в таблице метаданных MySQL, такой как INNODB_LOCKS, INNODB_TRX и INNODB_LOCK_WAITS в базе данных information_schema.Вы можете наблюдать ситуацию ожидания блокировки вашей бизнес-системы через эти таблицы. Вы также можете легко запросить взаимосвязь между транзакциями и ожиданием блокировки с помощью следующего оператора:

SELECT     r.trx_id waiting_trx_id,     r.trx_mysql_thread_id waiting_thread,     r.trx_query wating_query,     b.trx_id blocking_trx_id,     b.trx_mysql_thread_id blocking_thread,     b.trx_query blocking_query FROM     information_schema.innodb_lock_waits w         INNER JOIN     information_schema.innodb_trx b ON b.trx_id = w.blocking_trx_id         INNER JOIN     information_schema.innodb_trx r ON r.trx_id = w.requesting_trx_id;

результат:

waiting_trx_id: 5132
waiting_thread: 11
wating_query: update user set name='hehe' where id=3
blocking_trx_id: 5133
blocking_thread: 10
blocking_query: NULL

Суммировать:

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

2. В бизнес-системе должны быть сделаны соответствующие логические выводы для тайм-аута ожидания блокировки.

6. Резюме

Эта статья знакомит с несколькими проблемами параллелизма MySQL, которые мы обычно используем, на нескольких простых примерах и пытаемся придумать наши идеи по устранению этих проблем. В статье рассматриваются транзакции, блокировки таблиц, блокировки метаданных и блокировки строк, но проблемы параллелизма гораздо шире, чем перечисленные, например уровни изоляции транзакций, блокировки GAP и т. д. Реальных проблем параллелизма может быть много и они могут быть сложными, но идеи и методы устранения неполадок можно использовать повторно. проблема включает в себя репликацию, также необходимо поддерживать мониторинг ведущий/ведомый.

 

Использованная литература:

Цзян Чэнъяо "Механизм хранения InnoDB"

Ли Хунчжэ Ян Тинг "Руководство по устранению неполадок MySQL"

Хэ Сюньhedengcheng.com

 

Я рекламировал ===============================================

Meituan Dianping набирает Java-инженеров старших классов средней школы в Чэнду, Пекине и Шанхае с ежемесячной зарплатой 20-50 тыс. Если вам нужны внутренние рекомендации, вы можете написать мне: 360841519@qq.com

Эта статья основана наАтрибуция 2.5 Лицензионное соглашение с материковым КитаемПубликация, приветствуется перепечатка, вывод или использование в коммерческих целях, но необходимо сохранить авторство этой статьи.Ли Пинг(включая ссылки), конкретный метод работы можно найти здесь. Если у вас есть какие-либо вопросы или переговоры относительно авторизации, пожалуйста,Оставьте мне сообщение.
Add your comment

  1. #1-й этаж Прогулка бога-вола 3   2018-01-15 09:18
    хороший текстПоддержка(2)против (0) http://pic.cnblogs.com/face/348819/20130218153953.png
  2. #2-й этаж FaceSun   2018-01-15 13:49
    неплохоПоддержка(0)против (0)
  3. #3-й этаж домино   2018-01-15 19:38
    очень полезно, спасибоПоддержка(0)против (0) http://pic.cnblogs.com/face/u17196.jpg?id=29012616
  4. #4-й этаж CowryLee   2018-01-16 10:47
    Почему до сих пор люди используют таблицы myisam в продакшене?Поддержка(0)против (0)
  5. #5-й этаж Ганс   2018-01-16 11:13
    отличныйПоддержка(0)против (0) http://pic.cnblogs.com/face/859549/20170630173301.png
  6. #6 этаж вырезка   2018-01-16 14:07
    служба поддержкиПоддержка(0)против (0) http://pic.cnblogs.com/face/u41249.jpg
  7. #7 этаж alin_qu   2018-01-16 16:47
    InnoDB, если обновленное поле не проиндексировано, кажется, что таблицу нужно заблокировать.Поддержка(0)против (0)
  8. №8 Этажарендодатель] летящий красный шарф   2018-01-16 16:51
    @ alin_qu
    даПоддержка(0)против (0) http://pic.cnblogs.com/face/352511/20150610133629.png
  9. №9 Этаж большой камень   2018-01-17 09:28
    Оптимизация через sql - это бесконечное средство!
    Может ли арендодатель поделиться некоторыми решениями по настройке MySql и индикаторами производительности тестирования?
    Например, примерная таблица MySql, установленная по умолчанию, может выполнять w1 операций вставки в секунду или выполнять r1 запросов в секунду. После оптимизации ххх получаются вставки w2 или запросы r2. Это более интуитивно понятно.Поддержка(0)против (0) http://pic.cnblogs.com/face/u19592.jpg?id=28155008
  10. №10 этаж Daniel Cai   2018-01-17 11:28
    @ CowryLee
    Это нормально использовать myisam в продакшене, для других не проблема больше проверять и меньше писать.Поддержка(0)против (0) http://pic.cnblogs.com/face/45820/20161103205209.png
  11. # 11 этаж Мастер Сяочэнь   2018-01-17 14:57
    хороший текстПоддержка(0)против (0) http://pic.cnblogs.com/face/668104/20180314222145.png
  12. #12F ~Дождь идет грустный~   2018-01-17 16:24
    не могу читатьПоддержка(0)против (0) http://pic.cnblogs.com/face/856389/20171120165836.png
  13. №13 Этаж38927512018/1/18 14:54:59 owen zeng   2018-01-18 14:54
    Очень хорошая учеба,Поддержка(0)против (0) http://pic.cnblogs.com/face/603809/20180102114138.png
Обновить комментарийОбновить страницуBack to topЗарегистрированные пользователи могут оставлять комментарии только после авторизации.Авторизоватьсяилирегистр,доступдомашняя страница сайта.[Рекомендуется] Более 500 000 исходных кодов VC++: крупномасштабное промышленное управление конфигурацией, моделирование мощности САПР и библиотека исходного кода ГИС!
[Событие] Конференция 2050 — Встреча программистов Blog Park (5.25 Ханчжоу, город Юньци)
[Рекомендуется] 0 юаней для бесплатного использования сервисов HUAWEI CLOUD
【Событие】Специальная покупка нового облачного сервера Tencent, скидка 50% на облаке
腾讯云0502 Последние ИТ-новости:
· Телефон Meizu Android Go прошел сертификацию FCC и стоит менее 600 юаней.
· Один удар десять, анализ робота AGV логистики Suning
· Интерпретация: сколько стоит Xiaomi?
· Новый Surface Pro LTE официально представлен вместе с новыми конфигурациями Surface Pro.
· День 2 F8: новые возможности для социальных сетей и дизайна с помощью виртуальной реальности
» больше новостей... Последние статьи базы знаний:
· Как стать хорошим программистом?
· Надзорная дорога инженеров Rookie - от кампуса на рабочее место
· Как определить технические способности и уровень людей?
· Руководство для начинающих для самостоятельных студентов
· влюбиться в программиста
» Другие статьи базы знаний...

About


Ли Пинг, в настоящее время занимается дизайном и разработкой в ​​интернет-компании O2O. В свободное время он любит бегать, читать и играть в игры.

Нравится простая и эффективная рабочая среда, знакомые JavaEE, SOA, архитектура баз данных, оптимизация, эксплуатация и обслуживание системы, большие порталы, опыт построения финансовых систем. RHCE, ОСР MySQL. Участники проекта с открытым исходным кодом MyCAT.

Мой проект с открытым исходным кодом:
mycat-eye
nosql-eye

Никнейм:летящий красный шарф
Возраст сада:6 лет 5 месяцев
честь:Рекомендуемый блог
вентилятор:846
обрати внимание на:0 +Добавить подписку

последний комментарий

Файл эссе

календарь

< май 2018 г. >
день один два три Четыре пять шесть
29 30 1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31 1 2
3 4 5 6 7 8 9

мой ярлык

классификация эссе

Рекомендуемая таблица лидеров

Читать таблицу лидеров

www.spiga.com.mx

Copyright © 2018 Летающий красный шарф

Блог Парк