В данном случае можно было и не объявлять его абстрактным, но вот так разработчикам захотелось, чтобы явно указать программисту, что класс не следует использовать напрямую.
возможности по апгрейду памяти в данной модели - нет
Я помню, был тем самым ребенком, которому купили по минимуму
проблема с прибавкой ключей на следующего босса. То есть у меня всего 100 ключей например и когда пользователь бьет например босса номер 5, а другой(ие) разных, то получается так что добавляется через раз дополнительный ключ на какого-то из этих боссов
update payments set amount=amount-1 where (amount-1)>=0
1) Как получаются эти клиенты, я думал что на каждую джобу будет свой плодится, а нет, а как тогда, как оно с php-fpm работает?
2) Нормально это вообще, что timeouts 0? мне кажется нет
3) Почему ошибка вообще возникала? если логически подумать, то php-fpm стучался к редису и открывал соединение, получал данные и джоба успешно делала свои дела, спустя 300сек ЭТОТ ЖЕ pid php-fpm стучался в редис для очердной задачи, а соединение уже было закрыто и не мог достучатся, фейлился, так выходит? а что же тогда новое соединение не открыть, зачем старое юзать... (поэтому в эксперименте выше всегда 5 клиентов, когда джобов 50+ в моменте, тк юзаются старые подключения, верно мыслю?)
4) Какое вообще правильно решение в этой ситуации? (да, я понимаю, что многого не понимаю, конкретно как оно там под капотом устроено, вот и прошу объяснить)
Does Predis support UNIX domain sockets and persistent connections?
Yes. Obviously persistent connections actually work only when using PHP configured as a persistent process reused by the web server (see PHP-FPM).
Единственная сложность - это должно быть понимание асинхронности, но это безотносительно к языку.
Действительно, в какой-то степени, возможно будет проще написать web-sockets на Go, но это если у нас просто чат и не требуется обработка запросов, иначе реализация на тредах в Go могут оказаться гораздо сложнее, чем реализация через потоки в PHP.
И да, соглашусь, для такой задачи и если нет опыта, то лучше SSE.