Paper “RobinHood: tail latency aware caching – dynamic reallocation from cache-rich to cache-poor”

https://blog.acolyer.org/2018/10/26/robinhood-tail-latency-aware-caching-dynamic-reallocation-from-cache-rich-to-cache-poor/ 

• Cache - for the most frequent requests
• Tail? - no cache, will take longer to response
• Several services -> several caches. Reply after all of them have replied

  

• Wait for all the caches
• Doesn’t make sense to improve the “average” latency
• Robin Hood: uses cache to improve highest tail latency
• Контринтуитивно - улучшать tail latency
• В результате:
  • Улучшается время запросов (попадаем в кэш)
  • Уменьшается кол-во запросов к бэкенду, улучшая его производительность
• Почему нельзя статически определить, какой сервис хуже ведет себя? Потому что только в динамике
• Разные сервисы в разное время ведут себя, слабые точки проявляются по-разному
• Изменение поведения клиентов тоже ведет к изменению поведению системы -> попадание в кэши тоже меняется
• Поэтому только динамика
• RobinHood Caching System:
  • Каждые 5 секунд - забирать 1% его объема кэша на “общие нужды”
  • Цель - минимизировать 99 %ile, поэтому собираются все реквесты, попадающие в этот интервал, берется самый долгий под-реквест, ID этого бэкенда, и кол-во попаданий в каждый бэкенд.