php商城会频繁更新怎么做缓存,海量数据且更新频繁的列表该怎么优化

海量数据且更新频繁的列表该如何优化?

现在网站数据特别多,而且更新频繁,这样的站内容列表页面该如何优化?目前我们是生成了静态,可数据越来越多,这样每次生成消耗的时间会很可怕。有谁知道那些大网站的列表是如何处理的吗?跪求方案。。。。

------解决方案--------------------

竟然是大网站就要做一些大网站的做法.比如硬件上的跟进等等

更新频繁的东西就不适合做静态了,为什么更新频繁的东西要做静态呢?

如果是构架问题那就得考虑重新构架才行

如何优化可以引入memcache等 多台服务器共享数据的方式来处理。

或者动态的读取变动的部分内容.

------解决方案--------------------

由于更新频繁,所以列表页只需更换最近的几页就可以了

比如每页50条,那么原来的第1页在新增50条后就变成第2页了,并且内容与原先的第一页一样

另外需要注意一个事实:极少有人会沿着分页条翻页10次以上。而多使用搜索功能

------解决方案--------------------

更新频繁不适合在用静态了。前一分钟刚生成了 下一分钟就又来更新,那不是。。。

------解决方案--------------------

探讨

更新频繁不适合在用静态了。前一分钟刚生成了 下一分钟就又来更新,那不是。。。

------解决方案--------------------

统计到底哪些地方人查的地多,例如电子商品前一百个,可以把这一百个生成个静态页,多用用户搜索功能,避免导致用户无效又浪费的操作,数据库要是查的慢,除了算法语句、索引等优化,还可把数据进行分表等,例如,把火爆的电子商品从商品里提出来,可以缓解部分压力,大网站架构才是核心

------解决方案--------------------

那还是得看他的频繁更新到底是有多频繁才行。使用缓存技术是必须的.方法有很多种,构架可能需要重新设计...

一旦涉及到大流量高并发的时候都需要硬件上不断的跟进.没有实际的环境,也都只能泛泛的给你扯一扯了..

------解决方案--------------------

探讨

那还是得看他的频繁更新到底是有多频繁才行。使用缓存技术是必须的.方法有很多种,构架可能需要重新设计...

一旦涉及到大流量高并发的时候都需要硬件上不断的跟进.没有实际的环境,也都只能泛泛的给你扯一扯了..

------解决方案--------------------

我是进来学习的

实在不行换数据库?

------解决方案--------------------

这个得学习一下。

------解决方案--------------------

探讨

引用:

由于更新频繁,所以列表页只需更换最近的几页就可以了

比如每页50条,那么原来的第1页在新增50条后就变成第2页了,并且内容与原先的第一页一样

另外需要注意一个事实:极少有人会沿着分页条翻页10次以上。而多使用搜索功能

更新每天有几百的样子,唠叨老大,按你说的,后续的页面采用动态?

------解决方案--------------------

探讨

引用:

由于更新频繁,所以列表页只需更换最近的几页就可以了

比如每页50条,那么原来的第1页在新增50条后就变成第2页了,并且内容与原先的第一页一样

另外需要注意一个事实:极少有人会沿着分页条翻页10次以上。而多使用搜索功能

更新每天有几百的样子,唠叨老大,按你说的,后续的页面采用动态?

------解决方案--------------------

静态又不是万能的……根本就不应该静态,关键的地方不同的缓存措施即可

为了所谓的降低压力,这个措施居然成了压力,不搞笑?

------解决方案--------------------

採用單頁用戶訪問触发的方式来产生静态就好了,这么做的好处是后台生成单页更新,对于不常常访问的页面不会因为频繁做无谓的生成浪费资源,而常常访问的页面会被频繁更新生成,原理是:

假如某页面上次产生静态的时间是11点,当12点的时候有用户访问,那么只需要通过调用js的方式触发一下重新生成该页面就好了,当下一个访客访问的时候实际上看到的就是12点更新的页面了,这样每次更新的只有一页而已,不会占用太久的时间,而且js触发后台生成也不会影响到前台的访问.

如果你担心访客太多频繁更新的话,可以用php获取这个需要更新的页面上次的更新时间,如果更新时间距现在的时间小于半个小时则忽略更新,如果超过了半个小时,那么就重新生成新的静态页就好了.

我以前做的一个大型门户网站就是用这个方式来做自动更新的,完全不需要后台人工生成,不但不浪费人力而且效果也很棒.

------解决方案--------------------

探讨

静态又不是万能的……根本就不应该静态,关键的地方不同的缓存措施即可

为了所谓的降低压力,这个措施居然成了压力,不搞笑?

------解决方案--------------------

定时服务,自动生成页面,然后push过去就好啦

------解决方案--------------------

探讨

引用:

更新频繁不适合在用静态了。前一分钟刚生成了 下一分钟就又来更新,那不是。。。

不然!

假设每分钟有 100 人访问

生成一个静态页面只要操作一次

而动态需要操作100次

况且,更新列表页只是在有数据提交时才做的

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
您提到的确实是一个考虑因素。频繁更新缓存可能带来一些性能问题。在处理频繁更新的昵称动态显示问题时,可以考虑以下解决方案: 1. 延迟更新:不立即更新缓存,而是延迟一段时间后再更新。例如,在用户昵称发生变化后,等待一定的时间间隔(如几秒钟)再将更新操作应用到缓存中。这样可以避免过于频繁缓存更新,减轻对系统性能的影响。 2. 批量更新:将多个昵称变化的更新操作合并为一个批量操作。当有多个昵称需要更新时,将其收集起来,然后一次性更新缓存中。这样可以减少单个更新操作的次数,提高效率。 3. 异步更新:将缓存更新操作放入异步任务中处理。当用户昵称发生变化时,将更新操作放入消息队列或异步任务队列中进行处理,不阻塞主线程的运行。这样可以提高系统的响应速度,并降低对用户体验的影响。 4. 利用缓存过期机制:设置缓存的过期时间,让缓存在一定时间后自动失效。这样可以避免昵称变化导致缓存不一致的问题,而无需立即更新缓存。当缓存过期后,再根据需要重新从数据库或其他数据源中获取最新的昵称信息。 综合考虑实际需求和系统性能,可以选择适合的解决方案来处理昵称动态显示问题。重要的是根据具体情况进行评估和测试,确保系统在更新昵称时能够保持稳定和高效。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值