另一个问题是我有3个app服务器.所以内存缓存不起作用.
我正在考虑将数据保存在redis中并在每次调用时更新它,最后更新数据库.但由于我有3台服务器,我如何确保呼叫在队列中？
任何人都可以帮助建筑吗？
由于你没有给你的iops提供任何细节,我将在下面描述解决它的方法,按照递增的顺序,所有方法都是级联性的,这是最后一种方法实际上建立在以前的所有解决方案上：
client -> application layer -> database (save data here directly)
基本上在任何数据更新的地方我们直接将它传播到数据库级别.此架构中的主要块是数据库
这种方法需要注意的事项：
>插入查询比更新查询花费的时间更少,对于大学项目,您可以继续使用相同的主键更新行,并且它可以很好地工作.
>但是在任何中型应用程序中,单个表单修改需要30-40个请求,更新查询将阻止您的数据库资源.
>因此,请保留一个附录类型的模式,例如可能维护一个二级密钥,如状态,跟踪用户填写表单的级别,但继续为每次更新插入数据.并且始终根据插入的最新状态进行读取.
>为了进一步优化,应该使用诸如外键约束之类的索引
当这一步失败时,下一步是数据库本身,优化的下一步是,你正在处理的数据类型,你可以为非事务数据选择一个无架构的数据库,如mongo,dynamodb等
>使用无模式数据库对于大量非事务性数据非常有用,因为它们本身允许对同一行数据进行附录处理.
>对于其他优化,请使用二级索引更快地查询数据.
涉及应用层方法{应用层缓存}：
client -> application layer (save some data here then propagate later) -> database (Finally save here)
>当简单数据库无法按要求提供服务和扩展时,最简单的方法是将一些负载转移到您的API服务器上.因为相同的水平缩放更容易和更便宜.
>正如您了解内存缓存方法一样,但不要自行设计 – 需要多年了解大规模Web基础架构,然后人们才能在应用层上设计高效缓存.
>使用像Express Session这样的东西,我用它来制作一个有10个ec2 nodejs实例的web应用程序,每个会话存储大约15mb的用户数据.它可以很好地扩展,在所有服务器上维护唯一的用户会话数据 – 因此在每次自动更新时将数据保存到用户会话 – 在表单上提交从会话写入数据库.可以通过添加更多api服务器轻松扩展,最好用例用它来保存redis上的数据{为什么重新发明轮子？}
重新发明轮子：自定义级别应用程序层缓存db缓存db优化
client -> application layer (save some data here) ->{ Add your db cache}-> database (save data here finally)
>这是我们使用redis / Dynamodb / mongo设计我们自己的东西来充当主数据库的缓存的地方. (请注意,如果首先使用非事务性数据库,请使用附录方法 – 这非常适合通过添加非事务性数据库的包装来扩展事务性数据库)
>同样表达会话以相同的方式工作,实际上是通过在应用程序层上的redis上缓存数据,总是尝试尽可能减少对db的调用次数.
>因此,如果您有一个功能完备的应用程序层缓存和优化的数据库,那么就采用这种方法,因为它需要经验丰富的开发人员并且是资源密集型的,并且通常用于非常大规模的应用程序,例如我在快速会话后有一层redis缓存对于平均每秒300k reqs的应用程序
>此处的方法是将数据保存在用户会话中,将惰性写回应用于缓存. Maritain缓存分类帐然后写入您的主数据库.对于这种大规模系统中的排队方法,我编写了一个完整的独立微服务,它在后台工作,将数据从会话传输到redis到MysqL,关注如何维护队列,更多地了解优先级队列和后台工作者.我用了Kue is a priority job queue backed by redis,built for node.js.
> @L_301_3@
> php client for KUE
> Background Services
