我再问一个关于web系统设计的问题,大的系统设计架构主要解决的是,大数据和大并发下的,响应速度问题,或者说是查询速度问题,类似与进销存这样的管理系统,后台中的数据时刻都在变,如果这是一个有上万人使用的系统(比如京东,淘宝,沃尔玛) ,我们应该如何设计来解决查询优化的问题,
网上我查的资料,有很多关于方面的介绍,
1是数据库做镜像读写分离,可以提供大并发的查询熟读,
2是使用缓存来提高查询熟读,
那么什么情况下使用1,什么情况使用2.
像进销存这样的系统,缓存应该怎么设计,应该存些什么数据,同样的查询条件,2次查询的结果可能是不一样的,所以是不能缓存查询结果的,这种系统改怎么办.
缓存是缓解数据库读的压力，数据库分离是物理上解决数据库读的压力
缓存数据库的数据，不要缓存结果（数据更新比较大的就没必要缓存了）商品规模如何？用户量规模又如何？
建议可以考虑用 查询前置服务 的架构来做，大致几点：
1、开发专门的查询前置服务，它不是缓存，因为它必须保证可以查询得到且不存在失效；
2、前端系统进行查询时，直接访问查询前置服务，而不访问数据库；
3、前端系统执行交易时，可直接操作数据库；
4、查询前置服务，提供所有商品信息和库存信息的查询，直接维护在内存中；
5a、数据库设置触发器，将库存更新写入更新记录表，以供查询前置服务及时知道哪些库存被修改以主动更新内存中所维护的库存；
5b、借助Oracle的“数据变化通知”机制，查询前置服务在数据库上注册监听器，可即时发现数据变化并更新内存中所维护的库存；
6、查询前置服务要考虑集群以防止单点故障。
最后，如果不缺钱，可以考虑 用TimesTen 做查询前置服务。 1、查询量高，数据更新频度较高，时效性要求也较高的情况下；
2、查询量极高，数据更新频度低（意味着不需要频繁宣布缓存失效），时效性要求也较低的情况下。
缓存的问题集中在更新机制上，也就是要解决两个问题：
1、更新不敏感的情况下：缓存时效性应如何设置？30秒还是30分钟还是3小时？
2、更新敏感的情况下：后台数据更新了，怎么通知缓存失效甚至做主动更新？
必须说明的是：这两种技术并非不是你死就是我活，应该是配合着用。
不能缓存查询结果，这个说法不完全正确。从你看到信息，到下单，本身就可能存在变化。想想12306好了，你刷出来页面看到还有10张票，立即点击订票，十有八九就告诉你没了。所以时效性问题是一定存在的，架构师应该关注时效性遥控知道什么级别？对用户来说是否基本公平？