Lecture 16: Cache Consistency: Memcached at Facebook

  • Facebook's goal is to making features and selling ads
    • Only scaling if they need to

1.

  • Simple, single server

2.

  • Multiple Front End Servers
  • Still a Single backend database
    • Don't have to worry about things like distributed transactions

3.

  • Multiple Front End Servers, Multiple Databases Shared
    • a-g for database 1, g-q for database 2, q-z for database 3

4.

  • MEMCACHE Servers
    • get(key, value)
    • put(value)
    • a cache for data that is hit often "hot" data
  • but if a MEMCACHE fails, the database will fail
    • the database usually only sees a few percent that the caching layers sees!!!

5.

  • Stale data doesn't really matter
    • just some pictures from friends from last hour, etc.
  • Two datacenters
    • Try to avoid cross nation communication

Read and Write Lookaside Caching

  • delete for overwriting, because the data in the cache is stale
    • performance by:
      • partition
        • RAM efficient
        • not efficient for hot keys
      • replication
        • good for hot keys
        • few TCP connections

  • replication between datacenters

In One Region

  • sharded database
  • multiple clusters
    • FE to MC connections is \( O(N^2) \) so have to limit it and make it in clusters
    • Regional Pool Cache

Thundering Herd

  • a problem where a miss causes other front end servers to overload the database

  • instead use a lease
    • a number
    • invalidate the lease
    • when trying to write note lease is invalid, write is invalid

  • when deleting, use gutter memcache

Consistency

  • we get into a data race
    • problem - data is out of date forever!
    • use lease again
      • grant a lease (a number)