读写分离： 为保证数据库数据的一致性，我们要求所有对于数据库的更新操作都是针对主数据库的，但是读操作是可以针对从数据库来进行。大多数站点的数据库读操作比写操作更加密集，而且查询条件相对复杂，数据库的大部分性能消耗在查询操作上了。
主从复制数据是异步完成的，这就导致主从数据库中的数据有一定的延迟，在读写分离的设计中必须要考虑这一点。以博客为例，用户登录后发表了一篇文章，他需要马上看到自己的文章，但是对于其它用户来讲可以允许延迟一段时间（1分钟/5分钟/30分钟），不会造成什么问题。这时对于当前用户就需要读主数据库，对于其他访问量更大的外部用户就可以读从数据库。
适当放弃一致性：在一些实时性要求不高的场合，我们适当放弃一致性要求。这样就可以充分利用多种手段来提高系统吞吐量，例如页面缓存、分布式数据缓存、数据库读写分离、查询数据搜索索引化。
可以通过程序控制，将强一致性要求的功能（比如存钱、取钱）的读写操作均指向主数据库，或者将写操作采用“双写”的方式实现；而弱一致性（最终一致性）要求的功能（比如更新微博（写）、金融查询账户（读））实现读写分离。
剩下的一些尽量实现数据一致性的方案：
1、利用客户端缓存，减少对数据库的反复读取，当用户读取一次评论之后便将评论信息写入本地cookie，当用户在一段时间内不停刷新页面的时候，就不让他再读数据库了直接去cookie里面取数据。添加到数据库数据成功的同时也返回数据告诉客户端也添加到cookie里面去。这样用户就知道他自己成功评论了，而且不论他怎么刷都伤不到服务器。
2、利用缓存服务器的缓存，减少对数据库的反复读取，和cookie差不多，只不过是存在了服务器的内存里面。这样比读数据库快，但是需要注意这种情况下，如果用户玩命的刷，服务器还是很伤。就算是读内存还是得读服务器的东西。
3、没必要将所有的评论都放在数据库里，如果评论太多太久远的没有意义的就删了吧。或者干脆静态化了得了，减少数据库的体积。
4、关于同一时间并发的评论，直接先不写数据库，先全写到内存里去合并数量，然后按照数据库能接受的节奏，写进数据库。其实这个也是治标不治本，真正的洪流来了，怎么优化都没用。直接封IP吧。
最后的大招：
告诉用户他的数据已经提交，但是服务器更新需要一定的时间，请不要着急等30秒后刷新看看。这招最简单，根本就不用什么程序。