每次开会，一群大佬聊天，总是受益良多（哪怕我只是做在角落里瑟瑟发抖的小菜鸡…）。
所以我会在每次开完会都写一篇博客记录一下！
会有一些从业背景所需要的常识性东西，也是测试或者开发方面的。
比如之前做银行的测试，那对于银行的业务和常见的知识点是不是要熟记于心？（个人存取款、定期活期、代发代扣…）
那现在的也要积累这个行业的一些细节点（其实从业背景挺重要的，有些公司就注重这一点，这个以后再聊！）。
总结一下今天需要科普的知识点：
1.LBS
百度一下基础介绍。了解到是一种定位技术以后，想一想平时应用到的场景也就知道具体干啥了：我们上下班打卡的签到、点外卖显示周围的有哪些商家…
2.同步和异步
其实这个之前有所了解，举个例子：
我想和一朋友聊天，我有两个方式：打电话——发邮件
同步：我必须拨打朋友电话，等待那头他有空了接电话了，我才能和朋友聊天，有可能我要等他很久，再或者我等不及了，不停的拨打他的电话；
异步：我写了了一堆巴拉巴拉的话，点击发送，他有可能实时看到邮件，也可能有空的时候才会看到邮件才会回我；
网上百度一下总结：
3.降级
服务降级：主要是针对非正常情况下的应急服务措施;比如电商平台，在针对618、双11等高峰情形下采用部分服务不出现或者延时出现的情形。
为什么是非正常情况下呢，比如我要出差，如果经常出差的话，要带的衣服又非常多，那我买个大箱子就好；但是如果我基本出差，买个大箱子又用不到，那我只有个小箱子就够用，那么我只有在出差的时候把一些不重要的放弃了。放弃某一部分就是服务降级
1、服务降级的特征：
原因：整体负荷超出整体负载承受能力。
目的：保证重要或基本服务正常运行，非重要服务延迟使用或暂停使用
大小：降低服务粒度，要考虑整体模块粒度的大小，将粒度控制在合适的范围内
可控性：在服务粒度大小的基础上增加服务的可控性，后台服务开关的功能是一项必要配置（单机可配置文件，其他可领用数据库和缓存），可分为手动控制和自动控制。
次序：一般从外围延伸服务开始降级，需要有一定的配置项，重要性低的优先降级，比如可以分组设置等级1-10，当服务需要降级到某一个级别时，进行相关配置
2、降级的方式：
（1）、延迟服务：比如发表了评论，重要服务，比如在文章中显示正常，但是延迟给用户增加积分，只是放到一个缓存中，等服务平稳之后再执行。
（2）、在粒度范围内关闭服务（片段降级或服务功能降级）：比如关闭相关文章的推荐，直接关闭推荐区
（3）、页面异步请求降级：比如商品详情页上有推荐信息/配送至等异步加载的请求，如果这些信息响应慢或者后端服务有问题，可以进行降级；
（3）、页面跳转（页面降级）：比如可以有相关文章推荐，但是更多的页面则直接跳转到某一个地址
（4）写降级：比如秒杀抢购，我们可以只进行Cache的更新，然后异步同步扣减库存到DB，保证最终一致性即可，此时可以将DB降级为Cache。
（5）读降级：比如多级缓存模式，如果后端服务有问题，可以降级为只读缓存，这种方式适用于对读一致性要求不高的场景；
3、降级预案
在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：
一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；
警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；
错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；
严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级
4、降级分类
降级按照是否自动化可分为：自动开关降级和人工开关降级。
降级按照功能可分为：读服务降级、写服务降级。
降级按照处于的系统层次可分为：多级降级。
5、自动降级分类
（1）、超时降级：主要配置好超时时间和超时重试次数和机制，并使用异步机制探测回复情况
（2）、失败次数降级：主要是一些不稳定的api，当失败调用次数达到一定阀值自动降级，同样要使用异步机制探测回复情况
（3）、故障降级：比如要调用的远程服务挂掉了（网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常），则可以直接降级。降级后的处理方案有：默认值（比如库存服务挂了，返回默认现货）、兜底数据（比如广告挂了，返回提前准备好的一些静态页面）、缓存（之前暂存的一些缓存数据）
（4）、限流降级
当我们去秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时开发者会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。
参考：
http://blog.csdn.net/qq_26562641/article/details/53004578
查看原文：http://www.architecy.com/archives/265
网上找到的，介绍挺好的，也大体明白：当服务超出可承受范围内，会对执行的程序排个优先级，先做哪一些？哪一块不重要的暂时可以先放一放？
4. 测试的思考角度
每次开会，当运营或者开发提出一些需求或者功能点的时候，大神总是能第一时间想到这个需求可实施性、优先级、测试的侧重点、对现有功能有无影响/是否和现有的一些业务产生关联…
等等一大堆，这些都是很快的时间内想出来的！
所以每次我试图从他提问的问题的方面来看看他是从哪些角度来思考的…
-。 -
这个还在学习中，以后会整理。
嗯今天就想总结到这儿，先去搬砖啦！