查看: 1402| 回复: 0
跳转到指定楼层
上一主题 下一主题
收起左侧

[学习资料] 发现一篇关于cache strategies的好文

全局:

注册一亩三分地论坛,查看更多干货!

您需要 登录 才可以下载或查看附件。没有帐号?注册账号

x
发现这篇关于cache strategies文章讲的很好
https://codeahoy.com/2017/08/11/ ... oose-the-right-one/
我把要点记录下来了
Cache Aside
  Application checks from cache, if hit, returns data. If miss, reads from DB, returns data to client and updates cache.

  Use Case
    read-heavy workload

  Pros
    resilient to cache failures
    data model in cache can be different from DB

  Cons
    If write strategy is to write to DB directly, cache might be not consistent with DB (using TTL)
    If consistency is required, either invalidate cache entry, or use write through.

Read Through
  When cache miss, cache provider/library loads data from DB, populates cache and return data

  Diff from Cache Aside
    loading data is done by library or stand-alone cache provider
    data model has to be the same as in DB

  Use Case
    read-heavy workload

  Cons
    cache miss for every first-time request (can do warming or pre-heating)
    If write strategy is to write to DB directly, cache might be not consistent with DB (using TTL)

Write Through
  Write to cache and then cache provider/library writes data to DB

  Use Case
    combining Read Through and Write Through gets all the benefits of read-through and we also get data consistency guarantee, freeing us from using cache invalidation techniques. (DynamoDB Accelerator uses this)

Write Around
  Data is written to DB directly

  Use Case
    Write-around can be combine with read-through and provides good performance in situations where data is written once and read less frequently or never. For example, real-time logs or chatroom messages. Likewise, this pattern can be combined with cache-aside as well.

Write Back (Write Behind)
  Application writes data to cache and immediatly ack, after some time, cache write data back to DB

  Use Case
    Good for write-heavy workloads
    Resilient to DB failure
    If batching or coalescing is supported, reduce overall write to DB
    Redis use cache-aside and write-back to better absort spikes during peak load
    Most relational DB storage engines (i.e. InnoDB) have write-back enabled by default

  Cons
    If cache failure, data maybe permanently lost

求米~

评分

参与人数 6大米 +8 收起 理由
13-carotene + 1 给你点个赞!
JFreeman + 1 很有用的信息!
葡萄的奶茶 + 3 欢迎分享你知道的情况,会给更多积分奖励!
BZH + 1 赞一个
inh556 + 1 赞一个!

查看全部评分


上一篇:为什么consistent hashing能mitigate hotspot key problem?
下一篇:两轮SD,一轮白板画图,一轮verbal SD
您需要登录后才可以回帖 登录 | 注册账号
隐私提醒:
  • ☑ 禁止发布广告,拉群,贴个人联系方式:找人请去🔗同学同事飞友,拉群请去🔗拉群结伴,广告请去🔗跳蚤市场,和 🔗租房广告|找室友
  • ☑ 论坛内容在发帖 30 分钟内可以编辑,过后则不能删帖。为防止被骚扰甚至人肉,不要公开留微信等联系方式,如有需求请以论坛私信方式发送。
  • ☑ 干货版块可免费使用 🔗超级匿名:面经(美国面经、中国面经、数科面经、PM面经),抖包袱(美国、中国)和录取汇报、定位选校版
  • ☑ 查阅全站 🔗各种匿名方法

本版积分规则

>
快速回复 返回顶部 返回列表