语音交友app开发之资源隔离的思路与方法( 二 ) _线程

在使用了之后，系统线程隔离变得更灵活了。可以划分核心业务队列和非核心业务队列:
线程隔离小总结
进程隔离
进程隔离这种思想其实并不陌生,Linux操作系统中,利用语音交友app开发文件管理系统将各个进程的虚拟内存与实际的物理内存映射起来,这样做的好处是避免不同的进程之间相互影响,而在语音交友app开发的分布式系统中,线程隔离不能完全隔离故障避免雪崩,例如某个线程组耗尽内存导致OOM,那么其他线程组势必也会受影响,所以进程隔离的思想是,CPU、内存等等这些资源也通过不同的虚拟机来做隔离。
具体操作是,将语音交友app开发业务逻辑进行拆分成多个子系统(拆分原则可以参考:Redis集群拆分原则之AKF)，实现物理隔离，当某一个子系统出现问题，不会影响到其他子系统。
集群隔离
如果语音交友app开发中某个业务模块包含像抢购、秒杀、存储I/O密集度高、网络I/o高、计算I/O高这类需求的时候，很容易在并发量高的时候因为这种功能把整个模块占有的资源全部耗尽，导致响应编码甚至节点不可用。像上图的的拆分之后,如果某一天购物人数瞬间暴增,电商交易功能模块可能受影响,损坏后导致电商模块其他的浏览查询也无法使用,因此就要建立集群进行隔离,具体来说就是继续拆分模块,将功能微服务化。
解决方案
可以使用在微服务中隔离分布式服务故障。他可以通过线程和信号量进行隔离。
信号量隔离
说人话就是,很多语音交友app开发线程涌过来,要去获得信号量,获得了才能继续执行,否则先进入队列等待或者直接回调
最重要的是，信号量的调用是同步的，也就是说，每次调用都得阻塞调用方的线程，直到结果返回。这样就导致了无法对访问做超时（只能依靠调用协议超时，无法主动释放）
官网对信号量隔离的描述建议
理解下两点：
机房隔离
机房隔离主要目的有两个,一方面是将不同区域的用户数据隔离到不同的地区,例如湖北的数据放在湖北的服务器,浙江的放在浙江服务器,等等,这样能解决数据容量大，计算密集，i/o（网络）密集度高的问题,相当于将流量分在了各个区域。
另一方面,机房隔离也是为了保证安全性,语音交友app开发所有数据都放在一个地方,如果发生自然灾害或者爆炸等灾害时,数据将全都丢失,所以把服务建立整体副本（计算服务、数据存储），在多机房内做异地多活或冷备份、是微服务数据异构的放大版本。
如果机房层面出现问题的时候，可以通过智能dns、、负载均衡等技术快速切换,让区域用户尽量不收影响。
数据读写隔离
通过主从模式，将mysql、redis等数据存储服务集群化，读写分离，那么在写入数据不可用的时候，也可以通过重试机制临时通过其他节点读取到数据。
多节点在做子网划分的时候，除了异地多活，还可以在语音交友app开发做数据中心，所有数据在本地机房crud 异步同步到数据中心，数据中心再去分发数据给其他机房,那么数据临时在本地机房不可用的时候，就可以尝试连接异地机房或数据中心。
静态隔离
主要思路是将语音交友app开发的一些静态资源分发在边缘服务器中,因为日常访问中有很多资源是不会变的,所以没必要每次都想从主服务器上获取,可以将这些数据保存在边缘服务器上降低主服务器的压力。
爬虫隔离
建立合适的规则,将爬虫请求转移到另外的集群。
目前语音交友app开发都有API接口，并且多数都是开放的API接口。也就是说，只要有人拿到这个接口，任何人都可以通过这个API接口获取数据，如果是网络爬虫请求速度快，获取的数据多，不仅会对服务器造成影响,不用多久，爬虫方完全可以用我们API的接口来开发一个同样的网站，开放平台的API接口调用需要限制其频率，以节约服务器资源和避免恶意的频繁调用,在语音交友app开发中，对于web服务和网络爬虫的访问流量能达到5:1，甚至更高，有的系统有时候就会因为爬虫流量过高而导致资源耗尽，服务不可用。解决策略大致两个方面: