На Java я уже когда-то давно писал, еще до появления генериков, Это был мой первый язык, за программы на котором мне стали платить деньги))) Язык действительно похож на С++ и очень мне нравился...
На мой взгляд, основная задача тестировщика — убедиться, что функционал работает в основных вариантах использования. Отсутствие ошибок при вводе неправильных данных, то есть попытка сломать, — это уже второй этап тестирования.
Как поступают неопытные тестировщики — они сразу пытаются ввести неправильный пароль.
Опытные же тестировщики сначала пытаются войти по правильному паролю.
Swift еще не очень стабилен, если я правильно понял, туда постоянно добавляют новые фичи, которые могут сделать старый код нерабочим. В случае очень большой кодовой базы это может быть проблематично.
Во-первых, необходимо сгенерировать для своего биз-домена собственный DKIM-ключ (как это сделать, написано в статье). Без этого биз-домен с постмастером не подружить.
Ну а во-вторых, еще необходима доработка на нашей стороне. Которую мы как раз уже сделали и в течение месяца постараемся выложить.
Сообщение подписывается по домену залогиненного пользователя, и только для письма, сгенерированного пользователем. Всякие пересылки, автоответы, форвардинг не подписываются. Если обнаружите обратное — пишите, исправим, это баг.
Дефолтным доменом для дким-подписи является mail.ru, вы совершенно правы.
В будущем для биз-доменов сделаем дефолтным какой-нибудь отличный от mail.ru домен.
Да, в асинхронном случае реплика может немного отставать. Именно поэтому все запросы (и на чтение, и на запись) делаются на мастере. Реплика используется только в случае физического выхода из сторя сервера с мастером.
Клиент пишет только в один из серверов. Дальнейшей репликацией занимается сам Тарантул. В зависимости от политики (синхронная или асинхронная репликация) ответ на запрос клиент получит сразу или после успешной синхронизации мастеров.
Если репликация не пройдет, в синхронном случае клиенту вернется ошибка, а в асинхронном случае попытки синхронизации будут продолжаться до победного конца.
Если операций чтения сильно больше операций записи, оптимизация чтения за счет удорожания записи оправдана.
В текущей схеме все операции чтения идут на мастер, а реплика простаивает. Операции записи производятся и на мастере, и на реплике, просто на реплику они доезжают с задержкой.
В случае синхронной репликации чтение можно будет производить с любого сервера и нагрузка от чтения поделится между ними поровну. Запись будет по-прежнему производиться на обоих серверах, но уже синхронно. Это увеличит время, затрачиваемое на запись (из-за необходимости дожидаться, пока изменения доедут до второго сервера), но лишнюю нагрузку это создать не должно.
Получается, что нагрузка падает с (w + r) до (w + 0.5r) на первом сервере, и возрастает с (w) до (w + 0.5r) на втором. В целом максимальная нагрузка, которую сможет выдержать кластер, возрастает практически вдвое.
Если же хранилище практически write-only, то такая схема уже не работает. Это да. Ну так ее никто и не будет использовать для таких хранилищ.
Что если мастер применит апдейт, но ответ веб-серверу дойдет позже, чем 2 секунды (лаг сети, gc)?
В этом случае мы ответим клиенту, что не смогли применить изменения, хотя на самом деле их применили.
Вводя ограничения на время обработки команды, мы не избавляемся на сто процентов от подобных ситуаций, но сильно уменьшаем вероятность их возникновения.
По поводу синхронной мастер-мастер-репликации. Смысл подобной репликации в другом. Сейчас все запросы делаются в мастер (чтобы избежать рассогласованности данных). Даже на чтение. Синхронная репликация позволит делать запросы в любую из мастер-копий данных, выравнивая тем самым нагрузку на каждый из них. Т.к. разные мастера будут стоять в разных дата-центрах, то можно будет не ходить за данными за тридевять земель.
В случае поломки линка между ДЦ, не будут работать команды на модификацию, это правда. Но линки между ДЦ ломаются очень редко и за их здоровьем очень следят.
Синхронизация данных выполняется автоматически на стороне тарантула. Каждое состояние базы данных имеет свой числовой идентификатор. При изменении состояния идентификатор инкрементируется. На реплике крутится процесс синхронизации, который запрашивает и применяет к своей копии данных все изменения, произошедшие с мастером (изменения применяются последовательно, при этом наследуется идентификатор состояния).
В случае сетевых или других проблем синхронизация может произойти позднее, но в конце концов обязательно происходит.
Это отдельное приложение. Не опенсорс. Возможно, когда-нибудь вынесем в опенсорс, но пока там внутри слишком много нашей внутримейлрушной бизнес-логики. Балансировка MySQL пока не поддерживается.
Как поступают неопытные тестировщики — они сразу пытаются ввести неправильный пароль.
Опытные же тестировщики сначала пытаются войти по правильному паролю.
Ну а во-вторых, еще необходима доработка на нашей стороне. Которую мы как раз уже сделали и в течение месяца постараемся выложить.
Дефолтным доменом для дким-подписи является mail.ru, вы совершенно правы.
В будущем для биз-доменов сделаем дефолтным какой-нибудь отличный от mail.ru домен.
Если репликация не пройдет, в синхронном случае клиенту вернется ошибка, а в асинхронном случае попытки синхронизации будут продолжаться до победного конца.
В текущей схеме все операции чтения идут на мастер, а реплика простаивает. Операции записи производятся и на мастере, и на реплике, просто на реплику они доезжают с задержкой.
В случае синхронной репликации чтение можно будет производить с любого сервера и нагрузка от чтения поделится между ними поровну. Запись будет по-прежнему производиться на обоих серверах, но уже синхронно. Это увеличит время, затрачиваемое на запись (из-за необходимости дожидаться, пока изменения доедут до второго сервера), но лишнюю нагрузку это создать не должно.
Получается, что нагрузка падает с (w + r) до (w + 0.5r) на первом сервере, и возрастает с (w) до (w + 0.5r) на втором. В целом максимальная нагрузка, которую сможет выдержать кластер, возрастает практически вдвое.
Если же хранилище практически write-only, то такая схема уже не работает. Это да. Ну так ее никто и не будет использовать для таких хранилищ.
В этом случае мы ответим клиенту, что не смогли применить изменения, хотя на самом деле их применили.
Вводя ограничения на время обработки команды, мы не избавляемся на сто процентов от подобных ситуаций, но сильно уменьшаем вероятность их возникновения.
По поводу синхронной мастер-мастер-репликации. Смысл подобной репликации в другом. Сейчас все запросы делаются в мастер (чтобы избежать рассогласованности данных). Даже на чтение. Синхронная репликация позволит делать запросы в любую из мастер-копий данных, выравнивая тем самым нагрузку на каждый из них. Т.к. разные мастера будут стоять в разных дата-центрах, то можно будет не ходить за данными за тридевять земель.
В случае поломки линка между ДЦ, не будут работать команды на модификацию, это правда. Но линки между ДЦ ломаются очень редко и за их здоровьем очень следят.
В случае сетевых или других проблем синхронизация может произойти позднее, но в конце концов обязательно происходит.