上周看infoq出的一本电子书的时候，作者提到了一个面试题，题目是怎么利用一个500G硬盘大小，8G内存的机器对一个100G的文件进行字母排序？看到题目之后，100G的文件没法同时写入内存进行排序，因为只有8G内存，那只能先把这100G的文件进行拆分，因为程序运行本身也会占用一些内存，先将这100G的文件拆分成50个2G的文件，读入到内存中，通过快速排序进行排序，得到50个排好序的文件，然后将这些文件使用归并排序，两两合并，最后形成一个排好序的100G文件。其实这个面试题，考的知识点是分治的思想，8G的内存，排序100G的文件，表面看起来很难，如果采用分治的思维进行思考，一切变得有可能。这不仅仅只是一道面试题，更多的是一种思维方式。
有哪些场景我们会用到分治的思维，假如我们要读一本书《高性能Mysql》764页，好厚的一本，很多人很难有信心把它读完，如果利用分治的思维会怎么样？假如我花一年的时间去读这本书，那我只要平均每天读2页，我就能够读完这本书，从764到每天2页，后者对于大众来说更容易接受一点，我现在读一本书做计划就遵从这种方法，我利用了两周时间读完了《从零开始学架构》，该书308页，这项计划要求我每天需要读22页，主要利用早上和晚上睡觉前去完成。下一本书计划已经在路上《图解HTTP》250页，书不是很厚，而且内容相对较少，我准备花1周的的时间读完，这就要求我每天读35页，也不是说就一定要读和只读35页，可以根据自己的当天的情况进行适当调整，如果时间充裕可以多看一些，时间少一点就少读几页，但是尽量保证比较平均，不然做的计划就毫无意义。
对于一些销售型公司来说每个季度都有销售计划，比如第一季度要达成3000万的销售任务，为了完成这个目标，首先针对部门进行任务分解，比如线下销售人员较多，线上人员较少，线下销售完成2000万的销售任务，线上团队完成剩下的1000万。同样的逻辑继续针对每天、每个人员进行分治。需要根据销售对业务的熟练程度和能力进行分配，最后每个销售，每天就有一个销售任务的额度，这样每天根据实际情况去检验销售的完成情况，提前发现问题，如果销售一连几天没有达到需求预期，需要去了解情况，是不是遇到了什么困难，需要什么样的帮助。如果每个人每天都能达到预期，任务就有可能顺利完成，为什么是可能，因为时间在变，环境在变，政策在变，就如猎豹因为google公司取消了一个广告窗口位置，导致猎豹每天3万美金的广告收入飞灰湮灭。如果要让方案更完美，需要考虑各方面的因素，一般领导下达指标任务的时候，往往会在正常的基础上调20%，以应对那些突发情况。
技术方面利用分治解决问题的地方也很多，除了上面的面试题，还有像敏捷开发过程中的任务拆解，将一个大的需求，拆解成颗粒度很小的task任务。《从零开始学架构》作者把“拆”比作架构设计过程中的“屠龙宝刀”，微服务也是一种分治的思想，将大的应用拆分成一个个相对独立的微服务，好处是解耦，其他应用不用关心内部的实现细节，同时也更易于维护和扩展。一个高并发场景，百万流量，需要对流量进行分治，假如1台机器能够承受2万个请求/每秒，如果要应对百万流量的请求，可能需要50以上的机器去应对，因为机器之间的通信，也需要占用一些资源，当然这里只是表达分治的方式，其实真实场景可能使用更多的方法对流量的控制，比如增加缓存，cdn缓存，redis缓存等，限流：nginx限流、队列限流。熔断：当服务不可用进行熔断避免雪崩效应等等。
营销也经常使用分治的思维，现在很多知识付费的APP，如混沌大学、得到、极客时间、樊登读书会等，这些app差不多都有会员业务，年会员可能价格不等，“一年只要365，千万好书等你来读”，如果一下让你付365，你觉得还挺多的。但是如果改成“每天只要花1块钱，千万好书等你来读”，你可能更容易接受，这里就是使用了分治的思维，将365分摊到每一天，当然这里也有“价格锚定”的思维。
有了分治的思维，我们又多了一种解决问题的方法。分治过程中要把握颗粒度大小的问题，如果太大效果不明显，如果太小可能会带来额外的成本。拿微服务为例，拆的越细，会带来更多的维护成本，性能也会有所影响，原本只要调用一次服务需要20ms，如果拆成5个微服务，调用5次接口，可能需要100ms，如果其他的接口调用这个方法，也会受到影响。
合理利用分治思维，让一切变得有可能，以上是我对分治的一些理解，希望对你有所帮助。
网友评论