大多数管理者的困境


   
作为一名专业的教练，我经常会被问到：

教练，我的团队沟通不畅该怎么办？

教练，我的团队执行力不强要如何处理？

教练，我的团队里没有人才可用要如何做呢？

教练，我的团队士气很低怎样激励他们呢？

教练，我的团队经常达不成目标能给些建议吗？

教练，我的团队没有凝聚力有什么好的方法吗？

教练，我的团队没有能量，我要怎么给他们赋能呢？
……
 
教练与企业管理者的对话：



 
每当这个时候，我都会问这些企业的负责人，
 
一个鸡蛋如果从外给予压力，最终会怎什么呢？

他们有的说，会形成碎鸡蛋，也有人说，打破了可以做成炒鸡蛋，还有人说，可以用鸡蛋清敷在脸上做面膜，人类的想象力总是让人出乎意料……

我又问到，
 
那如果从里面给到动力，最后破壳而出，又会发生什么呢？

   
所有人的回答几乎都是一样的，一只有着生命力的小鸡.

我又问了一个问题，
 
我说假如你可以让你的员工具备破壳而出的生命力，你觉得企业会发生什么呢？

他们说，那简直太棒了，每个人都能自发地去做事，而且带着激情和动力，整个企业一定朝气蓬勃，充满斗志，但是，教练，我怎么做才能让他们具备这样的生命力呢？
 
我说，这是一个好问题，你觉得母鸡是怎么做的呢？

他们说，母鸡每天都会坐在鸡蛋上，哪都不去玩，全身心投入，给到鸡蛋持续的关怀和温度，并且坚持21天，直到小鸡可以从蛋壳中走出来.


   
那母鸡孵化小鸡这个过程给到你什么启发呢？
 
他们说，我也需要给到自己团队这样的关怀和支持，用心去孵化他们内在的动力，帮助他们释放出潜能，为他们创造适合他们成长的环境和土壤，以及给予更多的阳光和水，我相信他们一定能由内而外的活出有能量的状态，到那时无论什么困难和挑战都会迎刃而解.
 
每个人都是自己生命中的天才

 
他们分享完我就直接鼓掌，我一直都认为，每个人都是自己生命中的天才，而且我也是这样去践行的，无论是多大的企业家，还是最普通的员工都可以活出自己内在的智慧，并且解决生命中的困境.

马斯洛也曾说过类似的话，他说“人并不是被浇铸或塑造成人的，而是依靠自身实现潜能的，环境对人的成长象土壤、阳光和水对于植物一样，只能促进潜能的现实化。”
 
生命生长需要时间


无论是打破一个鸡蛋，还是一花一世界，万物皆具潜能，只是我们只盯在相上，只盯在结果上，却没有为结果投入更多的时间和耐心，即使我们今天看到的太阳的光芒，也不是今天太阳发出来的.

根据科学家的计算，从太阳发出光到地球需要8分20秒左右的时间，这就意味着，当我们生命中出现了至暗时刻，不用着急，也不用慌张，因为太阳光在路上，给它一点时间，至暗终会迎来光明.

以下文章由IT外包服务商北京艾锑无限科技发展公司整理

 

it运维知识教您缓存的三种方式
 
 
缓存是现在系统中必不可少的模块，并且已经成为了高并发高性能架构的一个关键组件。现在我们来分析一下使用缓存的正确姿势。

缓存能解决的问题

· 提升性能

绝大多数情况下，select 是出现性能问题最大的地方。一方面，select 会有很多像 join、group、order、like 等这样丰富的语义，而这些语义是非常耗性能的；另一方面，大多 数应用都是读多写少，所以加剧了慢查询的问题。

分布式系统中远程调用也会耗很多性能，因为有网络开销，会导致整体的响应时间下降。为了挽救这样的性能开销，在业务允许的情况（不需要太实时的数据）下，使用缓存是非常必要的事情。

· 缓解数据库压力

当用户请求增多时，数据库的压力将大大增加，通过缓存能够大大降低数据库的压力。

缓存的适用场景

· 对于数据实时性要求不高

对于一些经常访问但是很少改变的数据，读明显多于写，适用缓存就很有必要。比如一些网站配置项。

· 对于性能要求高

比如一些秒杀活动场景。

缓存三种模式

一般来说，缓存有以下三种模式：

· Cache Aside 更新模式

· Read/Write Through 更新模式

· Write Behind Caching 更新模式

通俗一点来讲就是，同时更新缓存和数据库（Cache Aside 更新模式）；先更新缓存，缓存负责同步更新数据库（Read/Write Through 更新模式）；先更新缓存，缓存定时异步更新数据库（Write Behind Caching 更新模式）。这三种模式各有优劣，可以根据业务场景选择使用。

Cache Aside 更新模式

这是最常用的缓存模式了，具体的流程是：

· 失效：应用程序先从 cache 取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。

· 命中：应用程序从 cache 中取数据，取到后返回。

· 更新：先把数据存到数据库中，成功后，再让缓存失效。

 

Cache Aside 更新模式流程图

注意我们上面所提到的，缓存更新时先更新数据库，然后在让缓存失效。那么为什么不是直接更新缓存呢？这里有一些缓存更新的坑，我们需要避免入坑。
 
避坑指南一

先更新数据库，再更新缓存。这种做法最大的问题就是两个并发的写操作导致脏数据。如下图（以Redis和Mysql为例），两个并发更新操作，数据库先更新的反而后更新缓存，数据库后更新的反而先更新缓存。这样就会造成数据库和缓存中的数据不一致，应用程序中读取的都是脏数据。


 

 

 

两个并发的写操作导致脏数据
 
避坑指南二

先删除缓存，再更新数据库。这个逻辑是错误的，因为两个并发的读和写操作导致脏数据。如下图（以Redis和Mysql为例）。假设更新操作先删除了缓存，此时正好有一个并发的读操作，没有命中缓存后从数据库中取出老数据并且更新回缓存，这个时候更新操作也完成了数据库更新。此时，数据库和缓存中的数据不一致，应用程序中读取的都是原来的数据（脏数据）。

 

 

 

两个并发的读和写操作导致脏数据
 
避坑指南三

先更新数据库，再删除缓存。这种做法其实不能算是坑，在实际的系统中也推荐使用这种方式。但是这种方式理论上还是可能存在问题。如下图（以Redis和Mysql为例），查询操作没有命中缓存，然后查询出数据库的老数据。此时有一个并发的更新操作，更新操作在读操作之后更新了数据库中的数据并且删除了缓存中的数据。然而读操作将从数据库中读取出的老数据更新回了缓存。这样就会造成数据库和缓存中的数据不一致，应用程序中读取的都是原来的数据（脏数据）。

 

 


 

但是，仔细想一想，这种并发的概率极低。因为这个条件需要发生在读缓存时缓存失效，而且有一个并发的写操作。实际上数据库的写操作会比读操作慢得多，而且还要加锁，而读操作必需在写操作前进入数据库操作，又要晚于写操作更新缓存，所有这些条件都具备的概率并不大。但是为了避免这种极端情况造成脏数据所产生的影响，我们还是要为缓存设置过期时间。
 
Read/Write Through 更新模式


在上面的 Cache Aside 更新模式中，应用代码需要维护两个数据存储，一个是缓存（Cache），一个是数据库（Repository）。而在Read/Write Through 更新模式中，应用程序只需要维护缓存，数据库的维护工作由缓存代理了。

 

 

 

Read Through

Read Through 模式就是在查询操作中更新缓存，也就是说，当缓存失效的时候，Cache Aside 模式是由调用方负责把数据加载入缓存，而 Read Through 则用缓存服务自己来加载。

Write Through

Write Through 模式和 Read Through 相仿，不过是在更新数据时发生。当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后由缓存自己更新数据库（这是一个同步操作）。

Write Behind Caching 更新模式

Write Behind Caching 更新模式就是在更新数据的时候，只更新缓存，不更新数据库，而我们的缓存会异步地批量更新数据库。这个设计的好处就是直接操作内存速度快。因为异步，Write Behind Caching 更新模式还可以合并对同一个数据的多次操作到数据库，所以性能的提高是相当可观的。

但其带来的问题是，数据不是强一致性的，而且可能会丢失。另外，Write Behind Caching 更新模式实现逻辑比较复杂，因为它需要确认有哪些数据是被更新了的，哪些数据需要刷到持久层上。只有在缓存需要失效的时候，才会把它真正持久起来。

 

 

 

Write Behind Caching 更新模式

总结

三种缓存模式的优缺点：

Cache Aside 更新模式实现起来比较简单，但是需要维护两个数据存储，一个是缓存（Cache），一个是数据库（Repository）。

Read/Write Through 更新模式只需要维护一个数据存储（缓存），但是实现起来要复杂一些。

Write Behind Caching 更新模式和Read/Write Through 更新模式类似，区别是Write Behind Caching 更新模式的数据持久化操作是异步的，但是Read/Write Through 更新模式的数据持久化操作是同步的。优点是直接操作内存速度快，多次操作可以合并持久化到数据库。缺点是数据可能会丢失，例如系统断电等。

缓存是通过牺牲强一致性来提高性能的。所以使用缓存提升性能，就是会有数据更新的延迟。这需要我们在设计时结合业务仔细思考是否适合用缓存。然后缓存一定要设置过期时间，这个时间太短太长都不好，太短的话请求可能会比较多的落到数据库上，这也意味着失去了缓存的优势。太长的话缓存中的脏数据会使系统长时间处于一个延迟的状态，而且系统中长时间没有人访问的数据一直存在内存中不过期，浪费内存。