网站开发工具排行,做淘客网站用什么程序,网站优化顺义案例,店面设计多少钱一个平方阿里妹导读#xff1a;响应时间长#xff0c;遇到性能瓶颈时#xff0c;开发者第一个想到的总是性能优化。《什么技能产品经理不会提#xff0c;但技术人必须懂#xff1f;》讲到了什么时候需要使用缓存。但缓存的用法是什么#xff1f;一旦缓存使用不当#xff0c;或稍… 阿里妹导读响应时间长遇到性能瓶颈时开发者第一个想到的总是性能优化。《什么技能产品经理不会提但技术人必须懂》讲到了什么时候需要使用缓存。但缓存的用法是什么一旦缓存使用不当或稍有不注意反而会翻车导致系统投入更多的维护成本陡增更高的复杂度。今天科怀就来讲讲缓存的正确使用姿势。 1. 常见概念
在合理应用缓存前需要了解缓存领域里相关的几个常用术语
1缓存命中表示数据能够从缓存中获取不需要回源 2Cache miss表示没有命中缓存如果缓存内存中还有内存空间的话会将数据加入到缓存中 3存储成本当没有命中缓存时回源获取后会将数据放置到存储中整个将数据放置到存储空间所需要的时间以及空间称之为存储成本 4缓存失效当源数据发生变更后意味着缓存中的数据失效 5缓存污染将不经常访问的数据放置到缓存存储空间中以至于高频访问的数据无法放置到缓存中 6替代策略当数据放置到缓存空间时由于空间不足时就需要从缓存空间中去除已有的数据选择去除哪些数据就是由替代策略决定的。常见的替代策略有如下这些
Least-Recently-UsedLRULeast-Frequently-UsedLFUSIZEFirst in First OutFIFO
由于存储空间有限替代策略要解决的核心问题是尽量保留高频访问的缓存数据降低缓存污染以提升缓存命中率和整体的缓存效率难点在于需要基于数据历史访问情况以一种合适的对未来访问情况的预估才能找到更佳的策略。
2. 访问缓存场景分析
使用缓存通常的操作是请求先访问缓存数据如果缓存中不存在的话就会回源到数据库中然后将数据写入到缓存中如果存在的话就直接返回数据。从整个过程来看缓存层就处于数据访问的前置环节分担数据库在高并发容易出现系统故障的风险所以在使用过程中需要对缓存层很谨慎的进行分析。在访问缓存数据时有常见的三大场景缓存穿透、缓存击穿以及缓存雪崩。
2.1 缓存穿透
现象每次请求直接穿透缓存层直接回源到数据库中给数据库带来了巨大访问压力甚至宕机。
原因访问数据会先访问缓存如果数据不存在缓存中才会查询数据库但是如果查询数据库也查询不出来数据也是说当前访问数据永远不会写入缓存中。这样就导致了访问一定不存在的数据就相当于缓存层形同虚设每次请求都会到db层造成数据库负担过大。
解决方案
方案一采用bloom filter保存缓存过的key在访问请求到来时可以过滤掉不存在的key防止这些请求到db层方案二如果db查询不到数据保存空对象到缓存层设置较短的失效时间方案三针对业务场景对请求的参数进行有效性校验防止非法请求击垮db。
2.2 缓存击穿
现象当某一key失效时造成大量请求到db层击垮存储层。
原因为了保证缓存数据的时效性通常会设置一个失效时间如果是热点key高并发时会有海量请求直接越过缓存层到数据库这样就会给数据库造成的负担增大设置宕机。
解决方案
方案一使用互斥锁当缓存数据失效时保证一个请求能够访问到数据库并更新缓存其他线程等待并重试方案二缓存数据“永远不过期”如果缓存数据不设置失效时间的话就不会存在热点key过期造成了大量请求到数据库。但是缓存数据就变成“静态数据”因此当缓存数据快要过期时采用异步线程的方式提前进行更新缓存数据。
2.3 缓存雪崩
现象多个key失效造成大量请求到db层导致db层负担过重甚至宕机。
原因缓存雪崩是指在我们设置缓存时采用了相同的过期时间导致缓存在某一时刻同时失效请求全部转发到数据库最终导致数据库瞬时压力过大而崩溃。
解决方案
方案一使用互斥锁的方式保证只有单个线程进行请求能够达到db方案二多每个key的失效时间在基础时间上再加上一个1~5分钟的随机值这样就能保证大规模key集体失效的概率并且需要尽量让多个key的失效时间能够均匀分布
2.4 总结
缓存穿透、缓存击穿以及缓存雪崩这三个术语很容易弄混也是读缓存中典型的三个场景问题做一下简单的总结是很有必要的。缓存穿透强调是获取本不存在的缓存数据请求必然会越过缓存层直接到达到存储层很明显这是利用业务规则的漏洞对系统发起攻击解决方案的核心原则是过滤这些非法业务请求与是否是热点数据、缓存失效时间等因素没有关系。
缓存击穿强调的是热点key的失效导致某一时刻大量请求会直接到db层解决方案的核心原则是规避数据库的并发操作。缓存雪崩强调的多个key的集体失效与key是否是热点数据并不是必然的因素解决方案的核心原则则让key之间的失效时间分布更加均匀避免集体失效的情况。
3. 数据更新场景分析
引入缓存后数据会分别存放到缓存以及数据库两个地方因此数据更新时需要涉及到这两处地方得更新并且更新时序的不同会有不同的结果。关于数据更新目前业界已经沉淀了Cache Aside PatternRead/Write through等多种方式。
3.1 Cache Aside Pattern
这是很通用的更新策略主要流程如下 主要涉及到如下几点
失效应用程序先从cache取数据没有得到则从数据库中取数据成功后放到缓存中。命中应用程序从cache中取数据取到后返回。更新先把数据存到数据库中成功后再让缓存失效。
Cache Aside Pattern在数据更新的时候是采用先更新数据库再失效缓存。为什么需要采用这样的方式来解决数据更新的问题先假设更新数据库以及缓存都会事务成功由于某一种更新导致的不一致性在下一章节进行讨论。
1为什么不是更新缓存而是失效删除缓存
❶ 并发写容易写覆盖造成脏数据问题当数据发生更新的时候针对缓存数据可以有两种方式来进行处理分别是更新缓存数据以及失效数据让下一次读请求重新从db中获取数据后重载入缓存中。假设更新缓存数据的话在并发情况下会存在多线程写缓存造成脏数据的问题如下图 如上图所示假设A、B两个线程A先更新数据库后 B再更新数据库然后分别进行更新缓存但是B先更新缓存成功A后更新缓存成功这样就导致数据库是最新的数据但是缓存中是旧的脏数据。而如果失效缓存数据的话可以保证下一次读请求回源到数据库将最新的数据载入到缓存中避免脏数据的问题。因此针对数据更新缓存采用失效的方式进行处理也可以参考这篇文章《Why does Facebook use delete to remove the key-value pair in Memcached instead of updating the Memcached during write request to the backend?》。
❷ 双写不同数据源容易造成数据不一致同时写数据库以及缓存数据任何一个更新失败都会造成数据不一致由于“物理失败”造成的数据不一致在下一个章节进行阐述。另外事务都成功无论是先更新缓存还是再更新数据库还是先更新数据库再更新缓存这两种情况在并发的情况下也很容易出现双写不成功操作时序如下图这种方式不推荐。 ❸ 先更新缓存再更新数据库 ❹ 先更新数据库再更新缓存 ❺ 违背数据懒加载避免不必要的计算消耗如果有些缓存值是需要经过复杂的计算才能得出所以如果每次更新数据的时候都更新缓存但是后续在一段时间内并没有读取该缓存数据这样就白白浪费了大量的计算性能完全可以后续由读请求的时候再去计算即可这样更符合数据懒加载降低计算开销。
2可能存在的更新时序
在确定数据更新后缓存会失效来进行处理的话针对数据库以及缓存更新时序就存在如下这几种
❶ 先失效缓存再更新数据库 ❷ 假设在并发的情况下按照这种更新时序会存在什么问题 如时序图所示线程A先失效缓存数据的时候B线程读请求发现缓存数据为空的话就会从数据库中读取旧值放入到缓存中这样就导致后续的读请求读到的都是缓存中的脏数据。针对这样的情况可以采用延时双删的策略来有效避免伪代码 如下
cache.delKey(key);db.update(data);Thread.sleep(xxx);cache.delKey(key);
主要是在写请求更新完数据库后进行休眠一段时间然后删除可能由读请求带来的脏数据存入到缓存。另外数据库如果采用的是主从分离的架构的话读出来的数据也有可能是主从未同步完成造成的脏数据。这种通过延时双删的方式需要线程休眠因此很显然会降低系统吞吐量并不是一种优雅的解决方式也可以采用异步删除的方式。当然可以设置过期时间到期后缓存失效载入最新的数据需要系统能够容忍一段时间的数据不一致。
❸ 先更新数据库再失效缓存 这是推荐的更新数据时采用的方式实际上这也是可能存在数据不一致的情况时序图如下 ❹ 假设缓存刚好到期失效时读请求从db中读取数据写请求更新完数据后再失效缓存后读请求将旧数据存入到缓存中这种情况也会导致脏数据的问题。实际上这种情况发生的概率很低要发生这种情况的前提条件是写数据库要先于读数据库完成一般而言读数据库相比于写数据库要耗时更短这种前提条件成立的概率很低。针对这种”逻辑失败“造成的数据不一致可以采用上面所说的异步双删的策略以及过期失效的方式来避免。
可以看出在并发的情况下如果条件苛刻的话这两种更新的时序都有可能导致脏数据的情况。只不过在大概率的情况下先更新数据库再失效缓存能够保证数据一致也是业界推荐的处理方式包括Facebook的论文《Scaling Memcache at Facebook》也使用了这个策略。当数据发生变更上需要考虑的是最新的数据放置在哪里很显然cache aside pattern 选择的是将最新的数据放到了db上cache asside pattern缓存靠边站因为数据不一致的情况大概率会存在需要根据业务场景选择合适的可信设备存储最新的数据。
3.2 Write/Read Through
Cache Aside Pattern对db以及缓存的更新逻辑是由调用方自己去控制很显然这是一个很复杂的过程。Write/Read Through对调用方而言缓存是作为整个的数据存储而不用关系缓存后面的db数据库的更新则是由缓存统一进行管理对调用方而言只需要和缓存进行交互整体过程是透明的。
Read Through当数据发生更新时查询缓存时更新缓存然后由缓存层同步的更新数据库即可对调用方而言只需要和缓存层交互即可Write ThroughWrite Through 套路和Read Through相仿不过是在更新数据时发生。当有数据更新的时候如果没有命中缓存直接更新数据库然后返回。如果命中了缓存则更新缓存然后再由Cache自己同步更新数据库。如下图所示来源于网络3.3 Write Behind Cache Pattern
这种模式是当数据更新的时候直接更新缓存数据然后建立异步任务去更新数据库。这种异步方式请求响应会很快系统的吞吐量会明显提升。但是因为是异步更新数据库数据一致性的保障就会变弱如果更新数据库失败则会永远的造成系统脏数据需要很精细设计系统重试的策略另外如果异步服务宕机的话还要考虑更新的数据如何持久化服务重启后能够迅速恢复。在更新数据库时由于并发多任务的存在还需要考虑并发写是否会造成脏数据的问题就需要追溯每次更新数据的时序。使用这种模式需要考虑的细节会有很多设计出一套好的方案是件很不容易的事情。
3.4 更新策略的思考
上面这四种更新策略是非常经典的也是业界经过大规模业务总结下来的经验如果认真分析这四种更新策略的话也会是受益匪浅在更新策略的设计我得理解是主要关注如下两个方面
最新的数据应该放置在哪里
缓存的存在是为了系统高性能利用内存的IO读取的高速的特性来提升系统的性能提高系统吞吐量另外缓存的存在会让一部分读请求不会到达db层分解了db的压力毕竟db是最容易出现瓶颈的地方。这是为什么利用缓存的两个重要原因。但是带来的问题就是数据会存在在两个地方分别是缓存以及数据库中当数据更新的时候就需要思考让”正确的数据应该放在哪个最可信的存储介质上“就需要结合业务性质在两个数据存储介质上进行选择。
Cache Aside Pattern选择先更新数据库再失效缓存这样可以保证最新最正确的数据一定会落在数据库中这样可以保证核心的业务数据在数据库中一定是可信的但是带来的问题是业务逻辑更复杂系统处理更新逻辑耗时更长。如果是非核心数据的更新可以选择write behind cache pattern的方式只需要更新缓存即可能够快速的响应。缺点是很容易造成数据不一致数据库中的数据不一定的就是最可信的数据。所以不同的更新策略实际上也是将最新的数据优先选择放在哪里更合适以及系统性能的一种权衡需要结合业务场景做好trade-off。
4. 数据不一致性
4.1 数据不一致的原因
由于引入缓存数据就会分散在两处不同数据源当数据更新时实时上很难做到数据一致除非采用强一致性方案这里不在进行讨论。在找出合适的解决方案前需要分析下存在数据不一致的主要原因才能对症下药
1逻辑失败造成的数据不一致在上一章主要分析了更新数据时的四种更新策略在并发的情况下无论是先删除缓存还是更新数据库还是更新数据库再失效缓存都会数据不一致的情况主要是因为异步读写请求在并发情况下的操作时序导致的数据不一致称之为”逻辑失败“。解决这种因为并发时序导致的问题核心的解决思想是将异步操作进行串行化。
2物理失败造成的数据不一致在cache aside pattern中先更新数据库再删除缓存以及异步双删策略等等如果删除缓存失败时都出现数据不一致的情况。但是数据库更新以及缓存操作是没办法放到一个事务中一般来说使用缓存是分布式缓存如果缓存服务很耗时那么将更新数据库以及失效缓存放到一个事务中就会造成大量的数据库连接挂起严重的降低系统性能甚至会因为数据库连接数过多导致系统崩溃。像这种因为缓存操作失败导致的数据不一致称之为”物理失败“。大多数情况物理失败的情况会重用重试的方式进行解决。
4.2 数据一致性的解决方案
在绝大部分业务场景中追求的是最终一致性针对物理失败造成的数据不一致常用的方案有消费消息异步删除缓存以及订阅Binlog的方式针对逻辑失败造成的数据不一致常用的方案有队列异步操作同步化。
4.2.1 消费消息异步删除缓存
主要流程如下图所示 4.2.2 订阅Binlog
主要流程如下图所示 4.2.3 利用队列串行化
在分析cache aside pattern发现在并发的情况下也会存在数据不一致的场景只不过发生的概率很低另外如果先删除缓存再更新数据库在并发读写的情况下也会存在数据不一致的情况。类似这种由于并发时序导致的数据不一致的情况都是因为写请求还没有结束读请求读取的是旧数据如果读请求在写请求之后处理即请求的处理能够串行化的话就能保证读请求读到的是写请求更新的最新的数据。
将请求进行串行化最常用的方式是采用队列的方式一个队列只能对应一个工作线程更新数据的写请求放置队列中等待异步处理读请求如果能从缓存中获取数据则返回如果缓存中没有数据就将读请求放置到队列中等待写请求数据更新完成。这种方案需要考虑的问题有
1读请求长时间阻塞如果队列中挤压了多个写请求则读请求会存在长时间阻塞的情况需要设置超时处理策略一旦超过超时时间则直接读取数据库返回避免长时间不响应另外在业务中需要进行压测考虑队列中在峰值情况下会积攒多少写请求如果过多需要考虑队列优化的方式和相应的解决方案
2多个队列分散压力可以根据数据项通过hash等路由方式创建多个队列并行执行来提升系统吞吐量
3操作复杂需要考虑全面由于采用队列来进行串行化那么要考虑队列的可用性队列阻塞以及服务挂掉后的容灾恢复策略是否健壮等等相对而言整体的方案需要考虑的点会有很多
这种方式可以做到数据强一致性由于串行化系统的吞吐量会下降很多并且操作复杂毕竟任何方案都会有利弊权衡的过程需要根据业务场景选择合适的技术方案。针对数据强一致性很有很多方案但基本上操作设计都很复杂在大多数业务场景满足数据最终一致性即可。
当然除了以上这三种通用的方法外为缓存设置过期时间以及定时全量同步也是接近最终一致性的最简单以及有效的方式。
5. 常见的几个场景问题
在分析数据更新的策略后发现正确使用缓存是一件很不容易的事情在实际使用缓存时还会有很多有意思的场景”坑“在这里进行一下总结
1过期还是不过期缓存数据针对缓存数据是否需要设置过期时间也需要结合场景来进行分析一些长尾商品大多数数据在业务中都是读场景更多并且缓存空间很大的话就可以考虑不过期数据。那是否就意味着这就是一份静态数据了当缓存空间已满时数据会根据淘汰策略移除缓存另外数据更新时也可以通过Binlog等其他方式进行异步失效缓存。
如果系统通过消息异步更新操作成本过高或者依赖于外部系统无法进行订阅binlog异步更新的话就需要来采用过期缓存数据来保障数据最终一致性。
2维度化缓存与增量更新如果一个实体包含多个属性在实体发生变更时如果将所有的属性全部更新一遍这个成本就很高况且只是其中的几个属性发生变化。因此将多个属性进行各个维度化进行拆解按照多维度进行缓存更新时只需要增强更新对应维度即可
3大value大value的问题要时刻警惕可以考虑将value进行压缩以及缓存时进行拆解然后在业务服务中进行数据聚合来避免大value的问题
4热点缓存问题针对热点数据如果每次都从远程缓存去获取会给缓存系统带来过多的负载会导致获取缓存数据响应过慢可以使用缓存集群挂载更多的从缓存读取数据从从缓存中获取。针对热点数据可以使用应用本地缓存来减少对远程缓存的请求负载
5数据预热可以预先将数据加载到缓存中方式缓存数据为空大量的请求回源到db。如果容量很高可以考虑全量预热如果容量优先就只能选择高频热点数据进行数据预热还需要关注是否有批量操作以及慢sql带来的性能问题在整个数据预热过程中需要有可靠的监控机制来保障
6非预期热点数据针对业务预估不足的热点数据需要有热点发现系统来统计热点key实时监控非预期的热点数据可以将这些key推到本地缓存中防止预估不足的热点key拖垮远程缓存服务。
7缓存实例故障快速恢复当某一个缓存实例故障后缓存一般是采用分片实例存储假设缓存key路由策略采用的取模机制的话会导致当前实例的流量迅速到达db层这种情况可以采用主从机制当一个实例故障后其他实例可以使用但是这种方式的问题在于水平扩展不够如果分片实例上增加一个节点的话会导致缓存命中率迅速下降。
如果key路由策略采用的一致性哈希的话某一个实例节点故障只会导致哈希环上的部分缓存不命中不会导致大量请求到达db但是针对热点数据的话可能会导致改节点负载过高成为系统瓶颈。针对实例故障恢复的方式有1. 主从机制对数据进行备份尽可能保障有可用数据2. 服务降低新增缓存实例然后异步线程预热数据3. 可以先采用一致性哈希路由策略当出现热点数据时到达某个阈值时降级为取模的策略。
6. 几个影响因素
影响缓存整体的性能会有很多大大小小的影响因素比如语言本身的特性的影响例如Java需要考虑GC的影响。还需要尽可能的提升缓存命中率等等多个方面总结下来核心的几个影响因素如下
1提升缓存命中率影响缓存命中率的几个因素
❶ 业务时效性要求缓存适合读多写少的业务场景并且业务性质决定了时效性要求不同的时效性要求决定了缓存的更新策略以及过期时间对时效性也低的业务越适合使用缓存并且缓存命中率越高 ❷ 缓存粒度设计通常而言缓存对象粒度越小就越适合使用缓存不会导致频繁更新导致缓存命中率下降 ❸ 缓存淘汰策略如果缓存空间有限不同的缓存淘汰策略也会影响缓存命中率如果淘汰的缓存数据后续被大量使用无疑就会降低缓存命中率 ❹ 缓存部署方式在使用分布式缓存时要做好容量规划以及容灾策略方式缓存实例故障后造成大规模缓存失效 ❺ Key路由策略不同路由策略会在节点实例故障后带来不同的影响如果采用取模的方式水平扩展时则会降低缓存命中率。通过这些分析提高缓存命中率没有放之四海而皆准的统一规则需要从这些角度去思考尽可能的在高频访问且时效性不是很高的业务数据上使用缓存。
2序列化方式使用远程缓存服务免不了需要经过序列化后在网络中进行数据传输那么选择不同的序列化方式对缓存性能会有影响。选择序列化方式时需要考虑序列化耗时、序列化后在网络传输中包大小以及序列化的计算开销。
3GC影响采用多级缓存以及大value时会采用应用本地缓存对于java应用就需要考虑大对象带来的GC影响。
4缓存协议了解不同的缓存协议的优缺点比如Redis以及Memcached协议根据业务场景进行选择。
5缓存连接池为提升访问性能需要合理的设置缓存连接池。
6完善的监控平台需要考虑是否有一套缓存的监控平台能够追踪缓存使用情况、缓存服务整体的性能以及一些非预期热点数据的发现策略等等这样才能综合整体的保障缓存服务的可用以及性能。
7. 多级缓存设计案例
从用户发出请求到到最底层的数据库实际上会经历很多节点因此在整个链路上都可以设置缓存并且按照缓存最近原则将缓存放置在里用户最近的地方提升系统响应的效果最为明显相应的提升系统吞吐量的效果就越为显著通过能够大大降低对后端的压力。在整个链路流程里可以添加缓存的地方有发起请求--浏览器/客户端缓存--边缘缓存/CDN--反向代理Nginx缓存--远程缓存--进程内缓存--数据库缓存。服务端多级缓存设计通用的技术方案如下 主要流程为
1请求先达到Nginx先读取Nginx本地缓存如果命中缓存则返回缓存数据。这里的负载均衡路由策略采用轮询的方式相对而言访问压力分布的更加均衡一致性哈希方式能够提升缓存命中率但是同时也会存在单点压力过大的问题可以考虑使用一致性哈希策略时流量达到一定阈值的时候切换成轮询的方式
2如果没有命中Nginx缓存则读取分布式缓存为了高可用以及提升系统吞吐量一般远程分布式缓存会采用主从结构这里读取的就是从缓存服务集群数据如果命中缓存则返回数据
3如果从缓存没有命中缓存则读取应用本地缓存堆内/堆外缓存这里的路由策略同样可以采用轮询或者一致性哈希。如果命中则返回数据并回写到Nginx缓存中为避免由于从缓存服务出现问题造成过大的流量冲垮数据库这里可以尝试读取主缓存服务
4如果所有缓存没有命中则查询数据库并返回数据并异步回写到主缓存以及应用本地缓存中。主缓存通过主从同步机制同步到从缓存服务集群中。这里会写到主缓存的时候需要考虑多个应用实例在异步写需要考虑数据是否会乱序的问题。
另外对于一些非预期热点数据比如微博中”某某明星结婚“等等热门话题带来的访问流量瞬间冲击到后端针对以上多级缓存设计可以通过引入热点发现系统来发现非预期的热点数据利用flume订阅Nginx日志然后通过消息进行消费最后通过storm等实时计算框架进行热点数据的统计当监控发现到热点数据将其推送到各个缓存节点上整体的缓存设计如下 8. 总结
为了追求高性能每个开发者最先使用的就是缓存也在潜意识里将缓存作为了系统性能瓶颈的一剂良药经过系统化的总结和分析缓存后就可以发现缓存如果使用不当真的就会事与愿违成为毒药并不会系统迭代出那个局部最优解。如果贸然的使用缓存需要考虑的地方真的很多稍有不注意反而会让系统投入更多的维护成本陡增更高的复杂度。那是不是就不使用缓存呢也不是缓存在高并发的情况下通过IO高速的缓存获取数据能使得每个请求能够快速响应并且能够大大提升系统吞吐量以及支撑更高的并发用户数在现有的高并发大流量的互联网应用中应用缓存的例子太多了也足以证明缓存在优化系统整体性能是一种行之有效的方案。
作为开发者不是每个人都有机会和机遇去挑战高并发的互联网架构以及高量级的访问流量和应用规模的那是不是就意味着这些通用的技术方案就不用深刻分析呢很显然不是单从缓存使用中就会发现在高并发下读写带来的数据不一致性分析下来就会有很多并发场景单线程下都是正常的但在并发下就会出现很多意想不到的case而这些分析的思路是最核心的也是开发者逐渐形成自己的方法论的有效训练途径。在系统化学习每一种技术组件时业界的通用解决方案都是经过历史经验慢慢沉淀下来的智慧如同品酒是需要静下心来好好去品的。
技术最终是服务于业务价值而业务规模扩张会反哺技术的创新要设计出一套适应于业务的合理的技术方案需要很深的内功需要既懂技术又要对业务理解十分深刻才行懂业务而不懂技术很难知道每种技术方案的局限性也就是经常所说的PPT架构师PPT很炫酷一顿操作猛如虎但是并不是最适合业务的那个解反而就像是跳梁小丑一样自嗨或者带着功利心去急于变现只有业务与技术结合能够得到最大价值的那个解就是最合适的方案需要在优与劣的trade-off上做出权衡。如果很懂技术但是不懂业务同样的就是废铜烂铁没办法发挥出功力。在不同的职业生涯阶段每个人的精力有限投入技术以及业务的精力分配也是不同的专注的点会有所不同就像业务与技术一样在人生的赛道中在不同阶段也需要迭代出那个最合适的局部最优解至于什么最合适答案在每个人心中
原文链接 本文为云栖社区原创内容未经允许不得转载。
