Основной открытый вопрос - что делать с новыми клиентами. Например, скажем, событие началось, и кто-то подключается к нему на несколько минут. Нужно ли им все с самого начала или просто с момента их подключения?
Если последний, я бы рекомендовал систему сообщений вместо добавления строк в строки. Один из способов - использовать Redis ' Pub / Sub . Это выглядит лучше всего, особенно если новым соединениям не нужно все с самого начала. Для более длительного хранения клиент, который слушает, как и любой другой, и запись в архиве - предпочтительно через локальный кеш, а затем загружает завершенную расшифровку после завершения или в процессе. Я бы держал потребности и код в реальном времени отдельно от запросов истории и архивов.
Другим способом было бы использовать упорядоченный набор, используя временную метку для времени, когда была сделана запись. В результате клиент только отслеживает последнее обновление и получает что-либо с этого времени. Документацию по заказанным комплектам можно найти здесь . Этот метод также предоставляет возможность выбрать область времени из стенограммы. Приложив немного математики, вы можете даже воспроизвести событие с точки зрения стенограммы, как если бы оно было живым. Если у вас есть десятки тысяч клиентов, тянущих всю стенограмму каждый опрос
Еще одним преимуществом упорядоченного набора меток времени является строковое кодирование. При использовании строк Redis и getrange необходимо использовать кодировки фиксированной ширины. Диапазон смещений байтов, а не смещений символов. Если вам нужна возможность поддержки, скажем, UTF-8, это может быть проблемой для вас.
Третий вариант - добавить строку текста в список. Это похоже на отсортированный набор, за исключением того, что ваш клиент хранит последний индекс (размер списка) и при каждом опросе пытается получить что-нибудь от lastIndex + 1 до конца.