一个最大的问题就是在于——笔者相信善于思考的读者应该也想到了——我既然有多个数据副本，从数据库提供读操作，主数据库提供写操作，而且这些操作发生在不同副本上，那我每次针对主数据库的写操作，是不是都需要把它复制到每个从数据库上呢？程序不是戏法，答案是肯定的。那随之而来的就是第二个问题，如何保证从数据库时刻和主数据库保持一致呢？这就触及了我们接下来要讨论的问题：主从不一致是读写分离主要面临的问题。
继续以电商网站为例，假设我们对一个电商网站进行了读写分离，然后用户Ａ下单购买了某商品之后，库存减一，这是一个针对主数据库的写操作，与此同时，用户Ｂ想查看同一个商品的库存，而这个操作时一个读操作，是针对从数据库的，如果这时候主数据库的数据还没有来得及被复制到从数据库，然后用户Ｂ就下单了刚好超过库存数量的单，是不是就出问题了呢？为了解决这样的问题，我们就需要进一步的优化。
副本实时性的解决方案
１．根据业务的实时敏感度决定是否采用读写分离。
例如，商品库存、订单等信息在交易频率较高的网站是一个实时敏感度很高的数据类型，我们就可以直接决定，这些信息一律指向主数据库，而其他信息，例如地址、信用卡、个人描述等，就可以采用读写分离。这其实就回到了一开始的问题：我们在什么情况下要使用读写分离？在这里我们就可以更细化地考虑这个问题：一个网站的业务类型是多种多样的，即使是在一个数据表中，也可能有的数据适合读写分离，有的不适合，在实际操作中，我们要尤其注意具体情况具体分析。
２．一旦对某信息发生了写操作，下一个读操作在主数据库上进行。
这个优化也很好理解，如果一个信息被更新了，那我们有理由认为从数据库可能没有及时得到最新信息，那我们就应该从数据肯定正确的主数据库上读取，而反之如果这个信息有一段时间没有被写过了，那我们就可以信任从数据库的信息是最新的。这样的操作的坏处也很明显：数据访问层必须得知道谁被最近被更新过。这样不仅对数据访问层增加了额外的逻辑，而且也使得数据访问层或多或少地与业务逻辑耦合起来。
３．对主数据库进行二次读取。
在某些情况下，我们可以通过一些方式检测到对从数据库的读取是过时的或者说失败的，那么在检测到这种条件满足时，数据访问层可以决定再从主数据库读取一次数据。这样的操作可以保证读取始终是最新信息，并且也平衡了主数据库和从数据库在解决副本实时性时的性能分担。但是如果这类的情况过多，会使得主从服务器的关系混乱，读写分离失去意义，因为主服务器承担的读操作过多，依然有性能下降的危险。
成本问题
最后，读写分离有着成本问题，或者说复杂性上的顾虑。事实上，在数据库的读操作频率极高时，是否选择读写分离从来都不是百分之百的出路。读写分离最大的问题就是在于，从数据库也是数据库（服务器），它也需要成本，当从数据库及其中间件、数据访问层消耗的建设和维护成本以及导致的故障频率增加时，还有很多别的选项值得考虑，例如缓存。
如果数据库中的某类数据被访问次数过多，网站建设者完全可以考虑通过缓存来缓解数据层的压力，具体细节请见下章。也希望读者在面临此类网站扩展的问题时，可以综合考虑各种选项，不要将自己的思路绑定在一个方向上。
文章来自：高性能服务器开发（微信公众号）
网友评论
最新评论