上古程序猿推戴经常使用Redis的执著理由 (上古教程)
最近,在知乎上看到这样一个疑问:
有些上古程序猿不时保持推戴经常使用怎样办?
终究用不用Redis?为什么用?怎样用?让咱们看看网友怎样说……
@灵剑
你不要通知咱们用不用redis, 你得通知咱们你为什么想要用redis,不用redis业务会有什么疑问?
天下没有收费的午餐,不动脑子间接上缓存/NOSQL或许会带来更多更重大的疑问。
繁多数据库最大的好处在于事务性成功便捷,由数据库自己保障。举个便捷的例子,下订单须要扣除一个库存,而后拔出一条订单条目,假设库存和订单都是数据库表项的话这个事务是无懈可击的。
![上古教程](https://tyye.cn/zb_users/theme/tpure/style/images/lazyload.png)
假设库存在redis里,订单条目是,通常就须要先写redis,成功之后再写数据库,假设写数据库失败了还须要回滚redis,假设最后这个回滚由于网络之类的要素失败了,就会多扣一个库存。
不要以为这些事件很好处置,事务性处置的复杂性远远超越你的构想,比如说还有写MySQL在提交的一瞬间衔接断了这种状况,你都没法判别提交究竟成功了还是失败了,那你的redis是回滚还是不回滚?
所以引入新的层必定要说清楚,你为了什么目标必定要用缓存/NOSQL,能接受什么样的分歧性模型,否则就是在胡闹。
审慎经常使用缓存是对的。
由于很多时刻缓存会覆盖掉一些疑问,甚至加大疑问。
从安保角度来说,缓存也是最容易被攻打的单薄点(缓存溢出攻打,不是缓存区溢出攻打,用少量有效的数据占满缓存空间使得系统性能断崖式上涨)。
所以通常做压力测试的时刻都是要求必定封锁缓存测试。
不单单是缓存,一切的两边件在处置一局部疑问的同时也会带来新的应战。譬如信息队列关于削峰填谷的效用十分显著,然而假设峰值继续的期间远远的超出了预计呢?而假设这时刻信息阻塞的监控还在方案中的话……
比如说散布式计算带来了有限扩容的或许,而分歧性疑问很多时刻会带来十分多的费事。
掂量是永远不会过期的。
我大概从95年开局学习编程,我想我应该算是一个上古程序员。
首先说一下你的疑问,这个疑问中的上古显著是带着点歧视的(当然你可以把它解释为调侃)。这个疑问其实并不是个技术疑问,问的其实并不是能否该用Redis,而是曾经十分自信的以为应该用,只是该怎样处置掉上古程序员保持不用这个疑问。
由于做的不是这一块,所以我团体并不了解Redis,然而可以说一上方对技术方向的分歧,我有什么处置方法: 用或许不用 某个系统/言语/技术/模块/组件/架构,或许用A还是用B,无非牵扯到几个方面的影响: 上班量、可裁减性、稳固性、性能、安保性、保养难度/可读性、费用 等等。而在不同的选用中通常都不太或许做到选用A在一切方面都强过选用B的,这时刻要做的,其实是一个对 各个方面的评价 ,乘以 这个名目对哪些方面更看重的权重 ,而后得出论断。
假设你能拿出你要用Redis的证据,也就是在哪些方面比不用Redis强,强了多少,有必要的话需写一些测试的程序来验证你的论断。而后用这些量化的数据去压服对方,这才是一个谨严的程序员应该做的,而不是跑到知乎过去讥嘲一个跟你 雷同想把事件做好,而只是理念不同 的共事。
最后说一下,多年的上班中,我发现有些程序员(很多)选用某个技术的要素,并不是基于上方所说的这些方面,而是:
而这几个,其实都不是真正的理由(第一个还好点,由于会所以上班量更少)。不知道答主是不是也有这种状况,倡导有则改之,无则加勉。
大家关于 "该不该经常使用Redis?" 这一疑问,有怎样的思索和想法呢?欢迎在留言区交换~
Redis是什么缓存机制
redis(RemoteDictionaryServer)远程数据服务内存高速缓存数据库。 C语言zd编写,数据模型为key-value,NoSql数据库。 希望对你有所启发。 apeit-程序猿IT中redis章节讲的不错,由浅入深,适合入门学习。
REDIS学习查看redis状态,以及rdb和aof两种持久化方案的区别
命令:redis-cli info //查看redis服务器状态的rdb : redis database 默认开启的,是将数据从内存备份到硬盘中。 aof:append only f 需要自己根据需要开启,是将执行命令存储在一个文件中。 建议看一下apeit-程序猿IT的文章《redis数据持久化》,讲的简单明了。
免责声明:本文转载或采集自网络,版权归原作者所有。本网站刊发此文旨在传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及版权、内容等问题,请联系本网,我们将在第一时间删除。同时,本网站不对所刊发内容的准确性、真实性、完整性、及时性、原创性等进行保证,请读者仅作参考,并请自行核实相关内容。对于因使用或依赖本文内容所产生的任何直接或间接损失,本网站不承担任何责任。