나 같은 신인이, JDK API를 시작하는 것은 의심의 NIO의 질문은 항상 다양한 질문이 있습니다, JVM에 대한 질문은 서비스 가용성 작업을 몇 년 후, 확장 성 또한 새로운 때 의심, 그것의 의심? 사실, 공통 주제 : 서비스 문제의 확장.
정상적인 상황에서 도로의 서비스 진화
의 처음부터 시작하자.
- 신생 기업에서 각 단량체 응용 프로그램 아키텍처까지, 기본적으로 모든 프로그래머의 SSM 및 SSH가 경험에 대해 이야기하는 것도 기본적으로 유사하다.
- 사업이 성장하면 RPC 응용 프로그램, 우리는 수준의 확장을 서비스 할 필요가 확장은 다음과 같이 서비스가, 거기에 상태를 저장 한, 매우 간단합니다 :
비즈니스 및 성장 우리의 서비스 관계가 복잡하고, 많은 서비스는 캐시에 연결할 필요는 DB 연결에 액세스 할 필요가 없습니다있을 때, 그것은 가치있는 연결 DB를 줄이고, 별도로 만들 수 있습니다. 도는 다음과 같습니다 :
나는 대부분의 기업들이이 단계에 있다고 생각합니다. 두보는이 문제 학생들을 해결하는 것입니다.
회사의 제품은 인기 경우, 사업은 ID 해시 또는 범위에 의해 하나, 당신은 확실히 하위 라이브러리 하위 테이블 생각합니다, 데이터베이스가 병목이 될 것이다, 더 느리게 급속한 발전, 더 많은 데이터를 SQL 작업을 계속 방법이 될 수 있습니다. 도는 다음과 같습니다 :
이 시간은 바로, 아무 문제가 없어야합니다. 데이터베이스의 I 단지 무제한 확장, 그것은 무제한 확장 응용 프로그램을 다시 고 복잡, 사용자가 더 보자.
이것은 또한이 문서의 제목입니다, 하위 라이브러리 하위 테이블 무제한 확장에게 그것을 해결할 수 있습니까?
사실, 위의 하부 구조처럼, 그리고 해결할 수 없습니다.
사실,이 문제와 문제는 RPC 다소 유사하다 : 데이터베이스 연결이 너무!
通常，我们的 RPC 应用由于是使用中间件进行访问数据库，应用实际上是不知道到底要访问哪个数据库的，访问数据库的规则由中间件决定，例如 sharding JDBC。这就导致，这个应用必须和所有的数据库连接，就像我们上面的架构图一样，一个 RPC 应用需要和 3 个 mysql 连接，如果是 30 个 RPC 应用，每个 RPC 的数据库连接池大小是8 ，每个 mysql 需要维护 240 个连接，我们知道，mysql 默认连接数是 100，最大连接数是 16384，也就是说，假设每个应用的连接池大小是 8 ，超过 2048 个应用就无法再继续连接了，也就无法继续扩容了。
注意，由于每个物理库有很多逻辑库，再加上微服务运动如火如荼， 2048 并没有看起来那么大。
也许你说，我可以通过前面加一个 proxy 来解决连接数的问题，实际上，代理的性能也会成为问题，为什么？代理的连接数也是不能超过 16384 的，如果并发超过 16384，变成 163840，那么 proxy 也解决不了问题。
怎么办？让我们再看看上面的架构图：
我们发现，问题是出在“每个 RPC 应用都要连所有的库”，导致扩容应用的同时，每个数据库连接数就要增加。就算增加数据库，也不能解决连接数的问题。
那怎么办呢？
单元化
单元化，听起来高大上，通常在一些 XXX 大会上，分享“关于两地三中心”，“三地五中心”，“异地多活”等等牛逼的名词的时候，单元化也会一起出现。
这里我们不讨论那么牛逼的，就只说“数据库连接数过多” 的问题。
实际上，思路很简单：我们不让应用连接所有的数据库就可以了。
假设我们根据 range 分成了 10 个库，现在有 10 个应用，我们让每个应用只连一个库，当应用增多变成 20个，数据库的连接不够用了，我们就将 10 个库分成 20 个库，这样，无论你应用扩容到多少个，都可以解决数据库连接数过多的问题。
注意：做这件事的前提是：你必须保证，访问你这个应用的 request 请求的数据库一定是在这个应用的。s
사용자의 DNS에서 온있을 때 그가 그 응용 프로그램을려고하고 있다는 것을, 다른 방법을 넣어, 그래서 잘 설정에서 DNS 전에 규칙이 조금 과장,하지만 확실히 당신이 도서관에 가서 알고되는 응용 프로그램 전에 있지만.
그래서,이 일반적으로 사용자 ID 해시, 해시 규칙 구성 방송 센터에 의해 예를 들어 규칙을 필요로한다. 따라서, 모든 구성 요소는 데이터베이스에 대한 액세스를 해결하기 위해 일관성있는 규칙을 관리 할 수 있습니다. 도는 다음과 같습니다 :
여기, 우리는 마침내 무한 확장의 문제를 해결했다.
최종적으로
하나의 응용 프로그램에서, 그리고 점차적으로 정상적인 배경의 진화 과정의 이야기를 하위 라이브러리 하위 테이블이 문제를 해결하기 위해 문제의 "무한 확장"만 단위를 해결하지 않을 것이다 알고있다. 의 단위는 복잡성을 가지고. 그러나 자명 한의 장점.
이 장치는 더 많은 아이디어를 제공합니다.
단위로 무한 확장의 문제를 해결하기 위해,하지만 우리는 단일 지점의 문제, 서비스, 즉 가용성 고려하지 않았습니다. 알다시피, 여기에 우리의 데이터베이스는 단일 지점입니다.