在进行技术积累的时候，总是会出现一种感觉，迷茫。。。从技术的发展角度来说，不知道下一步该怎么走。
当迷茫出现的时候，我们就会问一个问题，下一步会如何发展，下一步又如何的演进，接下来的规划是什么，怎么样才算是一个完美？
在这种时候，你总会听到别人的建议是，多做就好了，多实践就好了，那么本文就尝试从这种角度来分析别人的建议是否正确。
现实和梦想之间的距离
现实与梦想之间的距离，就像是暴风雨过后的彩虹，如果你经不起暴风雨的袭击，那么你还能看到彩虹么，并不会。。。
每个人都因为随机的因缘开始了一段技术旅程。
这几周因为随意看了一眼缓存，了解相关的缓存的关注点，从缓存的使用场景，缓存的性能，缓存的使用，缓存的搭建，缓存的原理，缓存的故障处理，缓存的性能监控指标。。。技术深入海，钻进去就不可自拔。
在最开始的时候，总是因为人群中看了一眼，就不能回头了。。。随着慢慢的了解，慢慢的深入，最终能到达什么样的地方。。。
慢慢的随着欲望的增多，就开始将各种组件进行搭建在一起，追求更高的性能，更高的可用性。。。从而使用缓存，增加性能；从而使用容器，节省服务器资源；从而使用python，分析缓存的原理，分析容器的原理，分析两者结合起来的性能。
那么下一步怎么走？下一步该进行什么样的测试？
在探讨下一步的时候，我们总是要回头看看我们的初衷，我们为什么要使用这个技术，我们为什么要采用这个中间件。。。不忘初心，一路前行。
在技术和梦想之间好像断了一层，如果梦想是精通此门技术，那么如何证明是精通了这门技术。。。这个中间依稀感觉少了点什么来促进达到这种梦想，看源码是否能证明精通了这门技术，那么如何证明精通就是一个问题，那么此时的问题就需要解决，到底要经历什么样的暴风雨，才能证明最后看到的是彩虹。
技术的狭隘性了解一下。。。。我们采用一个技术，采用一个组件，有很多种不同的途径，可能是因为别人提了一嘴，所以我们采用了；可能是因为这个比较流行，所以我们采用了；可能是我认为的某个大神用了，所以我们也就追随了。。。
技术的发展历史了解一下。。。别人采用一个技术，采用一个组件，有其必然的历史原因，可能是为了追求更快，所以采用了缓存；可能是为了追求更高的稳定性，所以采用主备；可能是为了维护方便，从而使用单系统架构。。。
破解狭隘性的关键在于看使用此种技术的业务场景，业务场景千千万，使用的方法千千万。。。使用缓存，是为了解决读的性能，而带来了新的问题，如何解决缓存穿透，缓存雪崩，缓存预热，缓存热点；使用数据库分库分表，是为了解决写的性能，是为了解决单台mysql服务器无法存储所有的数据，也带来了新的问题，如何解决数据的分布式存储，如何解决数据的存储均衡，如何解决跨机事务问题，如何解决数据的一致性问题，如何解决数据迁移的问题。。。。哪里有压力，哪里就有反抗，什么是推动力，是业务！！！
纵观整个技术栈的发展，业务都是核心的推动力，业务在持续给技术压力，采用新的技术解决目前存在的问题，新技术又会带来新的问题，从此业务持续发展，而顺便技术也在持续的发展与精进。。。。
业务如果是暴风雨，那么彩虹就是让业务更好的发展，提供更好的用户体验，追求极致的性能。。。业务的TPS从个到百，从百到千，从千到万。。。你必须采用新的技术才能支撑这种业务的发展，你必须采用一些新的组件来解决目前存在的问题，而新的组件又会带来新的问题。。
业务的并发数从量变到质变，用户响应时间变长，数据库的性能成为瓶颈，使用缓存可以缓解这种压力，开源组件中很多专门为缓存而生的，redis，memcache等各种各样的缓存，加入之后，又会有新问题的产生，缓存热点问题，缓存宕机问题，各种各样的timeout出错，redis server went away，不小心一个命令阻塞了服务器，造成了线上故障。。。从而又加以改进，进行各种高可用，高并发，从而就有redis sentinel高可用，redis cluster高可用，分布式缓存，随着系统越来越多，每次重新创建，重新搭建环境，维护成本太高。。从而加以改进，使用平台化，一个按钮创建一个redis集群，一个按钮创建redis sentinel高可用，自动加入监控，自动进行缓存热点的分布。。。一步一步解决问题，在这种推动力下，慢慢的熟悉缓存的场景，支持的并发，使用的性能，各种redis的改进，优化。。。各种问题都能碰到，慢慢就变成了redis的精通，缓存的精通。。。
那么碰到的问题数量就是支撑成为精通的必要条件么？分析问题，是了解一个系统最好的方式与方法。。。那么，没有这么好的业务场景，是否可以模拟这种持续的推动力来推动技术的了解和精通？
再次回到核心论点，为什么成长的时候会迷茫？综上所述，因为没有业务的持久压力来进行推动，从而有了迷茫，不知道下一步怎么走。。。那么又会产生一个问题，如果没有外界的压力，我们本身就很难成长？
这个问题又要回归到生活本身，我们成长的目的是为了什么？或许有人为了情怀，有人为了钱，为了更好的生活？不论出于什么目的，这都没有错，这只是每个人的追求与价值观。
成长的目的，从本质上来说，是个人的追求，是个人的梦想，而梦想需要搭配实际的生活，技术的应用也就是在业务上来体现，业务能有多大的规模，业务能有多复杂，这。。。才是造就梦想的出生地。
那么可以简单的理解为，技术的成长，就是为了应对业务的发展。。。无论是你被迫采用的技术，还是你积累的技术，都是为了应对下一次的业务场景，都是为了能更好的服务你的业务。
在此时，我们又回滚到上一个点，有的时候，别人给的建议是，做下去，一直做，你就会慢慢的精通了。。。这种说法说对也对，说错也错，对是因为如果每次都有要解决的问题，那么的确可以达到精通的目的，因为每次解决问题，适用的场景，业务验证，形成了一个闭环效应，你可以不断的验证假设，对与不对都很清楚，然后每次都加以改进，从而形成更好的，更加复杂的系统。。。错是因为，当你每次都漫无目的的做，重复的做，没有任何意思，最后自己都厌烦了，漫无目的了解一下。。。
业务场景模拟
在上面大段的讲述中，主要是为了引出业务，业务是推动技术发展的核心元素。
业务的发展，怎么来评判？用户数增多，系统越来越复杂。。。用户数增多，导致需要追求更好的性能，更高的可用性。。。停机一分钟，损失几百万。系统复杂度变高，一个bug影响整个系统，一个发布部署需要动用大量的人力。。。
伴随着业务的发展，可以看出公司的架构也在发展，会按照技术进行分类，分为各种部门，市场，运维，开发，运营，测试，业务的发展不断推动技术的发展，也会推动各种各样的发展，从而也让每个人的工作从全局的方面转变为更小的方面，这就是螺丝钉产生的原因。
那么从个人成长来说，怎么模拟这种业务发展？压力测试。。。
怎么模拟？在刚开始业务阶段，只是尝试使用一种技术，从而需要了解搭建，参数的配置运行情况，对技术不需要太高的要求；在业务发展之后，就会要求高可用，从而需要主备复制，HA自动切换，数据的分片存储；业务进一步发展，从而就需要自动进行环境创建，自动进行HA，各种各样的规范也相应出现，例如缓存中的key的命名，redis中推荐的数据结构，就会形成各种各样的最佳实践。。。
迷茫，是因为没有最佳路径来进行实践，如果没有来业务来验证这一切的改变，那么你所做的努力可能是折腾。。。学以致用了解一下。。。
模拟压力测试的时候，需要关注几个指标，业务的响应时间，从业务的角度来看；服务器的性能压力，从运维的角度来看；日志的调用链，从开发的角度来看。。。从而在进行压测的时候，你需要关注这些关键指标，响应时间，服务器的压力，报错的日志。。。大量并发压测，日志报错，模拟故障，解决问题。。。这也和上面所说的，解决了大量的问题，会让你成为这个系统的专家。。。
个人成长，总是在知识积累，也是对未来的技术的发展的一个预判。。。我判断错了怎么办？？？不要慌，问题很大，慌也没用。。。
对外我们总是说故障自愈，其实内部都懂是因为失控。。。
为什么会迷茫，因为字写的丑呗。。。因为这么炎热的夏天，风还不在。。。迷路的旅途最好玩不是么。。。方法总比借口多。。。
如果你看了这个文章，你还会迷茫，那么。。。天台了解一下。。。我在18楼等你。。。向死而生，毫不犹豫。。。