自动保存服务器架构

我想在服务器上保存一个冗长的表单input。 但是我不认为每个自动保存动作的db调用是最好的方法。

什么构成了解决这个问题的好方法?

另一个问题是,我有3个应用服务器。 所以在内存caching将无法正常工作。

我想保持在redis中的数据,并在每次调用更新它,最后更新数据库。 但是,因为我有3台服务器,我怎样才能确保呼叫在队列中?

任何人都可以帮助build筑?

这是扩展体系结构时遇到的一个非常经典的问题,但是随着实质上初始应用程序需要对数据库级别进行多次调用,让我们先进行优化。

既然你没有给你的iops提供任何细节,我将在下面描述解决这个问题的方法,按照负载的顺序,所有的方法都是级联的,这是最后一种方法实际上build立在所有以前的解决scheme上:

直接数据库方法{db调用每个自动保存操作}:

客户端 – >应用层 – >数据库(直接在这里保存数据)

基本上在任何数据更新上,我们直接将其传播到数据库级别。 这个模式中的主要块是数据库在这种方法中需要注意的事情:

  • 对于像Mysql这样的最常用的关系数据库:

    • 插入查询花费的时间less于更新查询的时间,对于大学项目,您可以不断更新对同一主键的行,并且它可以很好地工作。
    • 但是在任何中等规模的应用程序中,单个表单修改需要30-40个请求,更新查询会阻止你的数据库资源。

    • 因此,保留一种附录types的模式,如可能保持一个二级键,如状态,跟踪到用户已经填写表单,但不断插入数据为每个更新。 并始终按照插入的最新状态阅读。

    • 为了进一步优化,应该使用诸如外键约束之类的索引

    当这个步骤失败时,下一步是数据库本身,下一步优化是,你正在处理的数据的types,你可以select一个无模式数据库,如mongo,dynamodb等非事务性数据

  • 使用无模式数据库对于大量的非事务数据非常有用,因为它本身就允许对同一行数据进行增补

    • 为了进一步优化,使用二级索引来更快地查询数据

涉及应用层方法{应用层caching}:

客户端 – >应用层(在这里保存一些数据然后传播) – >数据库(最后保存在这里)

  • 当简单的数据库无法按需要服务和扩展时,最简单的方法是将一些负载转移到您的API服务器上。 因为同样的水平缩放更容易,更便宜。
  • 正如你理解内存caching的方法一样,尽pipe不要去devise你自己的内存 – 这需要多年的时间了解大规模的Web基础设施,然后人们也不能在应用层上devise一个高效的caching。
  • 使用类似于Express Session的东西,我使用了一个具有10个ec2 nodejs实例的web应用程序,每个会话存储大约15mb的用户数据。 它的尺寸精美,在所有服务器上保持唯一的用户会话数据 – 所以每次自动更新将数据保存到用户会话 – 在表单上提交从会话写入数据库。 可以通过添加更多的api服务器轻松扩展,使用它来保存redis数据的最佳用例{为什么重新发明轮子?}

重新发明轮子:自定义级别的应用程序层caching+数据库caching+数据库优化

客户端 – >应用层(在这里保存一些数据) – > {添加你的数据库caching} – >数据库(最后在这里保存数据)

  • 这是我们使用redis / Dynamodb / mongo来devise我们自己的东西来充当主数据库的caching的地方。 (请注意,如果首先使用非事务性数据库,那么可以使用附录方法 – 这纯粹适用于通过添加非事务性数据库的包装来扩展事务性数据库)

  • 同样,通过在应用层上将数据caching在redis上,也以同样的方式表示会话,尽可能减less对db的调用次数。

  • 所以,如果你有一个function齐全的应用层caching和一个优化的数据库然后去这个方法,因为它需要经验丰富的开发人员,是资源密集型的,通常用于非常大规模的应用程序,如我有一个快速会议后的Rediscaching层一个每秒300k次的应用程序

  • 这里的方法是将用户会话中的数据保存起来,然后将caching回写到caching中。 然后写入你的主数据库。 对于这样一个大规模系统中的排队方法,我已经编写了一个完整的单独的微服务,在后台工作,将数据从会话传输到Redis到MySQL,以便您关心如何维护队列以读取有关优先级队列和后台工作者的更多信息。 我使用Kue是由redis支持的优先级作业队列,为node.js构build。

  • 保持并行和顺序队列

  • PHP客户端的KUE
  • 后台服务

但是我不认为每个自动保存操作的db调用是最好的方法。

这是真正的问题,让我们从这个开始。 你为什么那么想? 你想自动保存,对不对? 这是保存用户工作的唯一的东西。

您列出的所有其他选项(memcached / redis,进程内caching)不仅不会节省用户的工作,而且还会计时炸弹。 想想那里可能会失败的所有事情:redis死亡,networking分裂,整个数据中心遭到雷击。

为什么创造所有的复杂性,当你可以…保存? 你可能会发现它并不那么慢(如果这是你的担心)。

该解决scheme成功地在全行业广泛采用 configuration一个3节点的Redis集群,负责数据的复制。 写入只发生在主节点上。

redis(master) – app server 1,redis(slave1) – app server 2,redis(slave2) – app server 3

使用slaveof:port命令添加一个从站是直接的。 复制是通过连线(不是临时磁盘存储)链接 – https://redis.io/topics/replication