有一天，产品一哥“林哥”来找我，跟我说：“小李，咱们现在一个需求，商品定时下架的逻辑，这个咱们能做到吗？”，我一想，今年的绩效跟着产品大佬走，当即拍着胸脯说道：“林哥，你就放一百个心，包在我身上~”，然后开始头脑风暴，毕竟要向前（钱）看。
案例
商品定时下架
方案一：消息队列
首先我想到当运营童鞋创建（或修改下架时间）商品后，就把该商品放到消息队列中，这样利用 RabbitMQ 的消息 TTL 加死信队列的特性，这个需求搞定，安排上线~
方案二：定时任务+消息队列
过了一段时间，架构师发哥心急火燎的来找我，我一看这阵势这是有大事吧，发哥不等我开口，说：“小李，快看看系统，运营童鞋来找我说，商品到下架时间还能买到；而且运维童鞋反应过节那天咱们的 RabbitMQ 那台 服务器 内存和硬盘不够用了，尽快处理下”。
我把两件事串联在一起就想到了出问题的点就是“过期自动下架”功能的问题。
第一个问题：商品到下架时间还能买到，我跟运营童鞋确认问题商品，发现很多商品的过期时间是3个月甚至更久，大致猜测可能是延迟时间过长导致了消息延迟失败，查了查默认在使用RabbitMQ的延迟消息功能时候，它的延迟极限是4294967296毫秒，也就是49.7天，很显然现有的功能是无法满足的运营需求，扑街~。
第二个问题：过节前夕 RabbitMQ 那台服务器内存和硬盘不够用，我去看运营后台发现创建了大量的新商品，那应该是大量延时下架商品放到消息队列中，以至于产生堆积。
基于以上两点，我做出以下两点改造：
搞定~
从这个案例中我借鉴的是Redis 的内存回收策略，因为 Redis 所有的数据都是存储到内存中的，所以在某些情况下需要对占用的内存进行回收。
Redis 中同时使用了惰性过期和定期过期两种过期策略。
策略一：惰性过期
只有当访问一个 key 时，才会判断该 key 是否已过期，过期则清除。该策略可以最大化地节省 CPU 资源，却对内存非常不友好。极端情况可能出现大量的过期 key 没有再次被访问，从而不会被清除，占用大量内存。
策略二：定期过期
每隔一定的时间，会扫描一定数量的数据库的 expires 字典中一定数量的 key，并清除其中已过期的 key。通过调整定时扫描的时间间隔和每次扫描的限定耗时，可以在不同情况下使得 CPU 和内存资源达到最优的平衡效果。
好兄弟可以点赞并关注我的公众号“javaAnswer”，全部都是干货。
Redis和Memcache的区别分析
1、 Redis和Memcache都是将数据存放在内存中，都是内存数据库。 不过memcache还可用于缓存其他东西，例如图片、视频等等。 2、Redis不仅仅支持简单的k/v类型的数据，同时还提供list，set，hash等数据结构的存储。 3、虚拟内存--Redis当物理内存用完时，可以将一些很久没用到的value 交换到磁盘4、过期策略--memcache在set时就指定，例如set key1 0 0 8,即永不过期。 Redis可以通过例如expire 设定，例如expire name 105、分布式--设定memcache集群，利用magent做一主多从;redis可以做一主多从。 都可以一主一从6、存储数据安全--memcache挂掉后，数据没了；redis可以定期保存到磁盘（持久化）7、灾难恢复--memcache挂掉后，数据不可恢复; redis数据丢失后可以通过aof恢复8、Redis支持数据的备份，即master-slave模式的数据备份。
0x770f48a4指令引用的0x00a4effc内存，该内存为read，什么意思？该怎么处理？
【1】硬件上的原因，主要是内存条不兼容，更换内存。 【2】系统或其它软件引起的，可用下述方法处理： （1） 系统本身有问题，及时安装官方发行的补丁，必要时重装系统。 （2） 病毒问题，杀毒 ；杀毒软件与其它软件冲突，卸载有问题的软件。 试用命令排除 开始－运行－ 输入cmd-- 回车，在命令提示符下输入下面命令 for %1 in (%windir%\system32\*) do /s %1 怕输入错误，可以复制这条指令，然后在命令提示符后击鼠标右键，打“粘贴”，回车，耐心等待，直到屏幕滚动停止为止。
进CF时 出现 0x77d2b38b指令引用的0x454e0014内存 该内存不能为“read
“0x????????”指令引用的“0x????????”内存。 该内存不能为“read”。 出现这个现象有方面的，一是硬件，即内存方面有问题，二是软件，这就有多方面的问题了。 一：先说说硬件：一般来说，电脑硬件是很不容易坏的。 内存出现问题的可能性并不大（除非你的内存真的是杂牌的一塌徒地），主要方面是：1。 内存条坏了（二手内存情况居多）、2。 使用了有质量问题的内存，3。 内存插在主板上的金手指部分灰尘太多。 4。 使用不同品牌不同容量的内存，从而出现不兼容的情况。 5。 超频带来的散热问题。 你可以使用MemTest这个软件来检测一下内存，它可以彻底的检测出内存的稳定度。 二、如果都没有，那就从软件方面排除故障了。 先说原理：内存有个存放数据的地方叫缓冲区，当程序把数据放在缓冲区，需要操作系统提供的“功能函数”来申请，如果内存分配成功，函数就会将所新开辟的内存区地址返回给应用程序，应用程序就可以通过这个地址使用这块内存。 这就是“动态内存分配”，内存地址也就是编程中的“光标”。 内存不是永远都招之即来、用之不尽的，有时候内存分配也会失败。 当分配失败时系统函数会返回一个0值，这时返回值“0”已不表示新启用的光标，而是系统向应用程序发出的一个通知，告知出现了错误。 作为应用程序，在每一次申请内存后都应该检查返回值是否为0，如果是，则意味着出现了故障，应该采取一些措施挽救，这就增强了程序的“健壮性”。 若应用程序没有检查这个错误，它就会按照“思维惯性”认为这个值是给它分配的可用光标，继续在之后的执行中使用这块内存。 真正的0地址内存区储存的是计算机系统中最重要的“中断描述符表”，绝对不允许应用程序使用。 在没有保护机制的操作系统下(如DOS)，写数据到这个地址会导致立即当机，而在健壮的操作系统中，如windows等，这个操作会马上被系统的保护机制捕获，其结果就是由操作系统强行关闭出错的应用程序，以防止其错误扩大。 这时候，就会出现上述的内存不能为“read”错误，并指出被引用的内存地址为“0x“。 内存分配失败故障的原因很多，内存不够、系统函数的版本不匹配等都可能有影响。 因此，这种分配失败多见于操作系统使用很长时间后，安装了多种应用程序(包括无意中“安装”的病毒程序)，更改了大量的系统参数和系统档案之后。 在使用动态分配的应用程序中，有时会有这样的情况出现：程序试图读写一块“应该可用”的内存，但不知为什么，这个预料中可用的光标已经失效了。 有可能是“忘记了”向操作系统要求分配，也可能是程序自己在某个时候已经注销了这块内存而“没有留意”等等。 注销了的内存被系统回收，其访问权已经不属于该应用程序，因此读写操作也同样会触发系统的保护机制，企图“违法”的程序唯一的下场就是被操作终止执行，回收全部资源。 计算机世界的法律还是要比人类有效和严厉得多啊！像这样的情况都属于程序自身的bug，你往往可在特定的操作顺序下重现错误。 无效光标不一定总是0，因此错误提示中的内存地址也不一定为“0x”，而是其它随机数字。 首先建议：1、检查系统中是否有木马或病毒?>2、更新操作系统，让操作系统的安装程序重新拷贝正确版本的系统档案、修正系统参数。 有时候操作系统本身也会有BUG，要注意安装官方发行的升级程序。 3、尽量使用最新正式版本的应用程序、Beta版、试用版都会有BUG。 4、删除然后重新创建WinntSystem32WbemRepository文件夹中的文件：在桌面上右击我的电脑，然后单击管理。 在服务和应用程序下，单击服务，然后关闭并停止WindowsManagementInstrumentation服务。 删除WinntSystem32WbemRepository文件夹中的所有文件。 （在删除前请创建这些文件的备份副本。 ）打开服务和应用程序，单击服务，然后打开并启动WindowsManagementInstrumentation服务。 当服务重新启动时，将基于以下注册表项中所提供的信息重新创建这些文件：HKEY_LOCAL_MACHINESOFTWAREMicrosoftWBEMCIMOMAutorecoverMOFs
发表评论