我在售票转售电子商务网站工作，我们遇到的一个问题是，在销售期间，我们的数据库受到数千次请求的轰炸。
持有门票的表格会不断更新和读取，这是该网站的主要瓶颈。
我们考虑从复制数据库中读取，但这些复制的服务器有时会不同步。
一个想法是在故障单表上使用触发器，并根据更新，插入，删除操作填充非规范化表，并使用此非规范化表进行读取。这可能会使查询更快一些。
我们已经考虑过CQRS，但由于我们网站的性质，以下原因我们认为它不适合：
每张票都是唯一的，因为它是由卖家上传的，而且多个买家将同时竞争相同的票。
我们会在列出热门活动时遇到突发流量，并且会以请求 - 响应的方式销售门票。
我们可以使用其他任何技术来分配一些负载吗？
答案 0 :(得分：1)
您能否告诉我们您正在使用的SQL Server版本（2008R2,2012，版本等）以及您正在运行的隔离级别？就触发器而言，它们很少与“性能提升”同义。 =）您是否能够识别数据库中的特定等待？读取是等待冗长的更新事务还是某种删除？或者您是否在数据库服务器上遇到内存压力？你有自动更新统计数据吗？你对这个表的写入是否也是突发性的？如果您的统计信息已过期，那么您可能会在整个过程中采用效率低下的查询计划。如果你还没有使用它，我强烈推荐Brent Ozar的sp_Blitz给你更多的见解。
一旦您了解了有关这些项目的更多信息，您可能会更好地了解是否需要实际分配负载而不仅仅是进行一些调整。
就负载分配而言，SQL Server AlwaysOn可用性组可能是一个答案，尽管它们需要一些精力充沛。可以创建异步复制的可读辅助，根据我的经验，至少通常保持相当低的延迟。同步副本也可以旋转，但这可能会使等待问题复杂化......您必须对该问题进行大量测试。
答案 1 :(得分：1)
你基本上是在构建另一个eBay，它们具有相同的缩放问题。
他们的架构有一些描述：http://www.quora.com/What-is-eBays-architecture，http://highscalability.com/ebay-architecture以及google上的许多其他内容。
基本上，它归结为尽可能使用异步处理（了解队列），并尽可能多地从主数据库服务器卸载，拥有一个良好的实时搜索服务器（不是您的数据库服务器），通过将尽可能多的逻辑移动到应用层来水平扩展。
这将要求您放弃ACID主体，并拥抱最终的一致性。最终并不意味着数小时，当您了解队列时，您将意识到允许0.5秒延迟可以实现更大的可扩展性。
所以，从一个后卫的架构，我建议你将你的搜索转移到一些相当实时的搜索引擎（如elasticsearch），将大部分元数据卸载到一些no-sql平台（如MongoDB或Cassandra）并保留您的数据库以处理针对故障单的出价。这些出价不应该直接进入数据库，而是应该放入队列中，这将强制执行排序，并允许另一个进程针对数据库执行它们。
这些架构更改中的任何一个都有助于您的负载，但异步更新将产生最大的不同。