Thrift 문제 집합, Thrift 를 생산 도구 로 사용 하려 고 합 니 다. 이것 부터 보 세 요.

1. 본문 이 계속 업데이트 되 기 때문에 블 로그 에 가서 최신 판 을 보 는 것 을 권장 합 니 다.본 고 는 cnBlogs 의 xxxteam 에서 나 온 것 입 니 다. 무절제 한 전재 입 니 다. 밝 혀 주 십시오.
 
2. Thrift 의 포 지 셔 닝
    Thrift 는 편리 하고 고성능 의 통신 미들웨어 일 뿐 진정한 의미 의 웹 서버 나 웹 서비스 server 가 아니다. 복잡 한 네트워크 환경 에 직면 하 는 기능 과 능력 이 없 기 때문에 시스템 내부 의 고속, 우수한 네트워크 환경 에서 만 사용 할 수 있다.
    즉, Thrift 를 IIS 나 apache 로 서 공공 네트워크 에 놓 고 사용자 에 게 직접 서 비 스 를 제공 하지 마 세 요. 7 * 24 의 끊 임 없 는 서비스 에 대해 책 을 보 내 는 것 이 불안정 하기 때 문 입 니 다.0.9.0 버 전에 서 제 가 있 는 thrift 서 비 스 는 사용자 가 1w 가 조금 많 고 평균 몇 초 에 한 번 밖 에 요청 하지 않 았 습 니 다. thrift C \ # server 는 평균 1 시간 에 한 번 무 너 졌 습 니 다.몇몇 친구 들 의 상황 은 더 심하게 붕괴 되 었 다.
 
3. Thrift 는 RPC 로 양 방향 통신 능력 을 가 진 socket - tcp 장 연결 이 아 닙 니 다.
    이 점 은 초보 자 를 겨냥 한 것 이다.socket - tcp 장 연결 은 연결 이 되 어 있 으 면 서로 다른 쪽 에 메 시 지 를 보 낼 수 있 고 연결 이 오래 유 지 됩 니 다.그러나 Thrift 는 다 릅 니 다. Thrift 도 tcp 를 기반 으로 하지만 응용 층 에 서 는 rpc 일 뿐 rpc 모델 을 준수 합 니 다.rpc 모델 의 운영 방식 은 http 와 비슷 합 니 다. 클 라 이언 트 가 서버 에 연결 을 하고 데이터 - > 서버 에서 데 이 터 를 되 돌려 달라 고 요청 합 니 다 - > 연결 이 끊 겼 습 니 다.따라서 rpc 모델 은 일회 성, 단 방향 통신 에 만 적합 합 니 다.여러 번 (오래 지속 되 는), 양 방향 통신 이 필요 한 친 구 는 여전히 성실 하 게 socket - tcp 를 사용 합 니 다.
    하지만 여기 서 한 가지 질문 을 드 리 겠 습 니 다.우선 tcp 는 진정한 긴 연결 이 아 닙 니 다.연결 을 유지 하려 면 한쪽 에서 다른 한쪽 으로 문의 패 킷 을 끊임없이 보 내야 하기 때문이다.tcp 프로 토 콜 은 자동 으로 이 일 을 했 지만 시간 이 너무 길 어서 몇 시간 만 에 보 냈 습 니 다.즉, tcp 로 연결 하면 상대방 이 몇 분 안에 이상 하 게 떨 어 지고 그 동안 명시 적 인 데이터 전송 이 없 으 면 tcp 는 최 악의 경우 몇 시간 후에 야 상대방 이 떨 어 진 것 을 발견 할 수 있다 는 것 이다.따라서 진정한 긴 연결 은 손 으로 심장 박동 가방 을 보 내야 한다.얼마나 자주 보 내 요?반 초?1 초?10 초?이것들 은 스스로 통제 해 야 한다.이 단계 에 이 르 러 문 제 는 간단명료 해 졌 다. 폴 링 체 제 를 사용 하여 서버 에 데이터 가 있 는 지 계속 물 었 다.있 으 면 빼.이 절 차 는 실제 적 으로 심장 박동 가방 의 체 제 를 모 의 한 것 이 고 이 절 차 는 높 은 통제 가 가능 하기 때문에 이 방법 을 추천 합 니 다.또한, tcp 장 연결 을 사용 하 는 것 은 기본적으로 이러한 방식 으로 nat 로 인 한 단 방향 연결 문 제 를 피하 고 싶 습 니 다.그래서 이런 방안 이 더 적합 하 다.
 
4. Thrift 가 매우 불안정 합 니 다.
    지금까지 Thrift 버 전 은 0.9.1 이 었 고 개발 진도 가 느 려 거의 1 년 만 에 0.1 개 버 전 을 업데이트 했다.thrift 라 는 프로젝트 는 매우 크 고 언어 와 관련 된 것 이 매우 많 기 때문에 그 자체 의 복잡 도가 매우 높 고 apace 의 다른 프로젝트 를 훨씬 초과 했다.그 다음으로 thrift 는 오픈 소스 이기 때문에 오픈 소스 는 무책임 성과 무책임 성 을 가진다. 또한 apache 라 는 기구 자체 의 일손 이 부족 하고 수준 이 부족 해서 Thrift 내부 에 구멍 이 많 고 각종 불안정 현상 이 발생 한다.Thrift 는 매우 편리 하지만 불안정 함 을 감안 하여 저 는 두 가지 제안 을 드 립 니 다.
    4.1 데 이 터 를 잃 어 버 릴 수 있 도록 Thrift 만 사용 하고 장시간 (최소 10 초 이상) 의 비 핵심 업 무 를 허용 합 니 다.
    4.2 Thrift 를 사용 한 친 구 는 Thrift 를 실행 하 는 서버 에서 문지기 서 비 스 를 해 야 합 니 다.문 지 키 는 개 는 제품 유형 으로 주체 프로그램 을 감시 하 는 역할 을 한다. 만약 에 주체 프로그램 이 고장 나 면 문 지 키 는 개 는 이 프로그램 을 죽 이 고 이 프로그램 을 다시 시작 할 것 이다.절차 도 간단 하 다.
        4.2.1 순환 시작 위치:
        4.2.2 문 을 여 는 개가 Thrift Server 를 방문 하 는 서비스
        4.2.3 방문 에 성공 하면 N 초 간 휴식 을 취한 다음 순환 시작 위치 로 돌아 가 순환 을 계속 합 니 다.이 N 은 업무 성능, 지연 시간 허용 과 관련 이 있 습 니 다.5 ~ 10 초 로 설정 하 는 것 을 권장 합 니 다.너무 길 지도 말고 너무 짧 지도 마 세 요.
                접근 이 성공 하지 못 하면,
                     횟수 < = M 회 성공 하지 않 으 면 횟수 + 를 성공 하지 못 하고 K 초 간 휴식 한 후 마지막 으로 순환 시작 위치 로 돌아 가 순환 을 계속 합 니 다.M 과 K 값 은 업무 성능, 지연 시간 허용 과 관련 이 있 습 니 다.M 은 3 회, K 는 1 초 로 설정 하 는 것 을 권장 합 니 다.
                     그렇지 않 으 면 Thrift Server 프로 세 스 를 죽 이 고 1 초 후에 다시 시작 한 다음 실패 횟수 를 1 로 설정 하고 순환 시작 위치 로 돌아 가 순환 을 계속 수행 합 니 다.
 
5. Thrift 의 기본 js 패 키 징 은 동기 화 된 원 격 호출 방법 을 사용 합 니 다.이 방법 이 오래 접근 하면 js 가 시간 을 초과 하거나 결 과 를 성공 적 으로 되 돌 릴 때 까지 웹 인터페이스 가 계속 걸 립 니 다.
    ajax 를 사용 해 야 비동기 접근 을 할 수 있 습 니 다. 안 타 깝 게 도 thrift 는 ajax 를 사용 하지 않 았 습 니 다.하지만 thrift 에는 비동기 키워드 가 있 으 니 한번 해 보 세 요.
 
6. Thrift 는 0.9.0 인 AS3 에 버그 가 있다.비교적 복잡 한 데이터 구 조 를 사용 할 때 첫 번 째 필드 가 i32 이면 이 필드 는 AS3 의 read 방법의 정적 정의 오류 로 인해 첫 번 째 i32 필드 의 값 을 가 져 올 수 없습니다.첫 번 째 필드 를 폐기 필드 로 하면 이 문 제 를 해결 할 수 있 지만 이런 해결 방안 은 분명 비 과학적 이 고 알 이 아 프 며 절조 가 없다.
 
7. Thrift 의 C \ # http client 는 자동 회수 기능 (gc) 이 없습니다.따라서 일정한 횟수 를 사용 한 후에 예 를 들 어 100 번, 예 를 들 어 transport 를 close () 에 수 동 으로 주 고 dispose () 를 마지막 으로 모든 변 수 를 다시 new 해 야 합 니 다.이렇게 하지 않 으 면 클 라 이언 트 가 방문 할 때마다 메모리 가 조금 증가 하고 이 메모리 들 은 메모리 부족 (64bit app) 이나 넘 침 (32bit app) 으로 인해 프로그램 이 무 너 질 때 까지 방출 되 지 않 습 니 다.
 
8. Thrift 의 C \ # HTTP Server 는 client js 에 접근 할 때 매우 느리다.테스트 를 통 해 서버 가 client 의 요청 을 받 았 기 때문에 client 에 응답 한 것 은 데이터 전송 은 가장 기본 적 인 통신 단위, 한 단위 로 한 단위 로 전송 하 는 것 이다. 즉, 아무리 큰 데이터 양 이 라 고 해도 몇 개의 kb 몇 개의 kb 로 전송 되 는데 이런 전송 방법 이 느 리 지 않 은 것 이 이상 하 다.【TTransport.cs】：

1 public virtual void Write(byte[] buf)

2 {

3     Write (buf, 0, buf.Length);

4 }

 
또는 그 하위 과정 [TStreamTransport. cs]:

1 public override void Write(byte[] buf, int off, int len)

2 {

3     if (outputStream == null)

4     {

5         throw new TTransportException(TTransportException.ExceptionType.NotOpen, "Cannot write to null outputstream");

6     }

7     

8     outputStream.Write(buf, off, len);

9 }

 
버퍼 가 없어 서 데 이 터 를 만 들 면서 Write 를 만 들 고 성능 이 낮 습 니 다.
 
9. 다른 문제 가 있 으 면 QQ 군 23152359 가입 을 환영 합 니 다.안에 thrift 를 연구 하 는 큰 소 들 이 많 습 니 다.