AMQP / ZeroMQ / RabbitMQ를 사용하는 이유
자신의 라이브러리를 작성하는 것과는 반대로.
우리는 여기서 자체 분할 서버 풀이 될 프로젝트를 진행하고 있습니다. 한 섹션이 너무 무거워지면 관리자가이를 분할하여 별도의 프로세스로 다른 컴퓨터에 배치합니다. 또한 새 서버에 연결하는 데 영향을 미치는 연결된 모든 클라이언트에게 경고합니다.
서버 간 및 프로세스 간 통신을 위해 ZeroMQ를 사용하는 것이 궁금합니다. 내 파트너는 자신의 것을 선호합니다. 이 질문에 답하기 위해 커뮤니티를 찾고 있습니다.
저는 상당히 초보 프로그래머이며 메시징 대기열에 대해 방금 배웠습니다. 내가 검색하고 읽었을 때 모든 사람들이 모든 종류의 메시지 대기열을 사용하는 것 같지만 그 이유는 무엇입니까? 자신의 라이브러리를 작성하는 것보다 더 나은 점은 무엇입니까? 왜 그렇게 흔하고 왜 그렇게 많습니까?
라이브러리를 작성하는 것보다 더 나은 점은 무엇입니까?
앱의 첫 번째 버전을 출시 할 때 아무 것도 없을 것입니다. 요구 사항이 잘 정의되어 있고 요구 사항에 맞는 메시징 시스템 (작은 기능 목록, 작은 소스 코드 등)을 개발하게됩니다.
이러한 도구는 실제로 애플리케이션을 확장하고 더 많은 기능을 추가해야하는 첫 번째 릴리스 이후 에 매우 유용 합니다. 몇 가지 사용 사례를 알려 드리겠습니다.
- 앱은 리틀 엔디안 머신 (x86, 인텔 / amd)에서 빅 엔디안 머신 (sparc / powerpc)과 통신해야합니다. 메시징 시스템에는 몇 가지 엔디안 순서 가정이 있습니다. 가서 수정하십시오.
- 바이너리 프로토콜 / 메시징 시스템이 아니도록 앱을 설계했으며 이제는 대부분의 시간을 파싱하는 데 소비하기 때문에 매우 느립니다 (메시지 수가 증가하고 파싱이 병목이 됨). 바이너리를 전송할 수 있도록 조정합니다. 고정 인코딩
처음에는 LAN 내부에 3 대의 시스템이 있었기 때문에 모든 시스템에 대한 모든 것이 눈에 띄게 지연되지 않았습니다. 클라이언트 / 보스 / 뾰족 머리 악마 보스가 나타나서 관리하지 않는 WAN에 앱을 설치할 것이라고 알려줍니다. 그런 다음 연결 실패, 지연 시간 등이 발생하기 시작합니다. 메시지를 저장하고 전송을 다시 시도해야합니다. 나중에 : 코드로 돌아가서이 물건을 연결하고 즐기십시오.
전송 된 메시지에는 응답이 있어야하지만 전부는 아닙니다. 일부 매개 변수를 전송하고 결과적으로 스프레드 시트를 예상하고 전송하고 확인하는 대신 코드로 돌아가서이 내용을 연결하고 즐기십시오.
- 일부 메시지는 중요하며 수신 / 전송에는 적절한 백업 / 지속성이 필요합니다. 왜 물어? 감사 목적
그리고 내가 잊은 다른 많은 사용 사례 ...
직접 구현할 수 있지만 그렇게하는 데 많은 시간을 소비하지 마십시오. 어쨌든 나중에 대체 할 것입니다.
그것은 질문과 매우 흡사합니다. 당신이 직접 작성할 수 있는데 왜 데이터베이스를 사용합니까?
대답은 한동안 사용되어 왔으며 다양한 사용 사례에서 잘 이해되는 도구를 사용하면 시간이 지남에 따라 요구 사항이 진화함에 따라 더 많은 성과를 거둘 수 있다는 것입니다. 한 프로젝트에 두 명 이상의 개발자가 참여하는 경우 특히 그렇습니다. 새 프로젝트로 변경하는 경우 대기열 시스템의 지원 직원이되고 싶습니까? 도구를 사용하면 그런 일이 발생하지 않습니다. 다른 사람의 문제가됩니다.
적절한 사례 : 지속성. 하나의 메시지를 디스크에 저장하는 도구를 작성하는 것은 쉽습니다. 그 저울과 수행 아니라 persistor를 작성 하고 다양한 사용 사례에서, 안정적으로, 그리고 것은 관리하고, 지원하는 저렴한는 어렵다. 누군가가 얼마나 힘든지 불평하는 것을보고 싶다면 다음을보십시오 : http://www.lshift.net/blog/2009/12/07/rabbitmq-at-the-skills-matter-functional-programming-exchange
어쨌든 도움이 되었기를 바랍니다. 반드시 자신의 도구를 작성하십시오. 많은 사람들이 그렇게했습니다. 문제를 해결하는 것이 무엇이든 좋습니다.
나는 ZeroMQ를 직접 사용하는 것을 고려하고 있습니다-따라서이 질문을 우연히 발견했습니다.
모든 요구 사항을 충족하는 메시지 대기열 시스템을 구현할 능력이 있다고 가정 해 보겠습니다. Roll-Your-own 접근 방식에 대해 ZeroMQ (또는 기타 타사 라이브러리)를 채택하는 이유는 무엇입니까? 단순-비용.
ZeroMQ가 이미 모든 요구 사항을 충족한다고 가정 해 보겠습니다. 완료해야 할 일은 빌드에 통합하고 doco를 읽은 다음 사용을 시작하는 것입니다. 그것은 당신 자신을 굴리는 것보다 훨씬 덜 노력해야합니다. 또한 유지 관리 부담이 다른 회사로 이동되었습니다. ZeroMQ는 무료이므로 ZeroMQ 팀을 포함하도록 개발 팀을 성장시킨 것 같습니다.
소프트웨어 개발 사업을 운영했다면 타사 라이브러리를 사용하는 것과 자체 라이브러리를 사용하는 데 따른 비용 / 위험의 균형을 맞출 것이라고 생각하며,이 경우 ZeroMQ를 사용하면 성공할 수 있습니다.
당신 (또는 오히려 당신의 파트너)이 많은 개발자처럼 "Not Invented Here" 신드롬 으로 고통 받고 있습니까? 그렇다면 태도를 조정하고 ZeroMQ 사용을 재평가하십시오. 개인적으로 나는 Proudly Found Elsewhere 태도의 이점을 훨씬 더 선호합니다. ØMQ를 찾는 것을 자랑스럽게 생각합니다.
편집 : ZeroMQ 를 사용해야하는 이유 에 대해 이야기하는 ZeroMQ 개발자의 비디오 를 보았습니다.
라이브러리를 작성하는 것보다 더 나은 점은 무엇입니까?
메시지 큐잉 시스템은 트랜잭션 방식으로, 개념적으로는 클라이언트로 사용하기 쉽지만 특히 지속적 큐를 고려할 때 구현 자로서 제대로 이해하기 어렵습니다. 빠른 메시징 라이브러리를 작성하지 않아도된다고 생각할 수 있지만 트랜잭션과 지속성이 없으면 메시징 시스템의 모든 이점을 얻을 수 없습니다.
이 컨텍스트에서 지속성은 메시징 미들웨어가 서버가 다운 될 경우 처리되지 않은 메시지를 영구 저장소 (디스크)에 보관함을 의미합니다. 다시 시작하면 메시지를 처리 할 수 있으며 재전송이 필요하지 않습니다 (발신자는 문제가 있는지조차 알지 못함). 트랜잭션은 트랜잭션 방식으로 다른 큐에서 메시지를 읽고 다른 큐에 메시지를 쓸 수 있음을 의미합니다. 즉, 모든 읽기 및 쓰기가 성공하거나 (하나 이상 실패하면) 성공하지 못합니다. 이는 데이터베이스와의 인터페이스에서 알려진 트랜잭션과 크게 다르지 않으며 동일한 이점을 제공합니다 (오류 처리를 단순화합니다. 트랜잭션이 없으면 각 개별 읽기 / 쓰기가 성공하는지 확인해야합니다. 하나 이상의 실패가 발생하면 성공한 변경 사항을 롤백하려면).
자신의 라이브러리를 작성하기 전에 여기에서 0MQ 가이드를 읽으십시오 : http://zguide.zeromq.org/page:all
RabbitMQ를 설치하기로 결정하거나 이미 모든 어려운 부분을 수행했기 때문에 ZeroMQ 위에 라이브러리를 만들 가능성이 있습니다.
약간의 시간이 있다면 시도해보고 자신의 구현을 시작하십시오! 이 연습 문제를 통해 이미 테스트를 거친 라이브러리를 사용하는 것이 얼마나 지혜로 운지 확신 할 수 있습니다.
참고 URL : https://stackoverflow.com/questions/1823705/why-use-amqp-zeromq-rabbitmq
'Programing' 카테고리의 다른 글
| 인라인 함수의 정적 변수 (0) | 2020.10.24 |
|---|---|
| Java의 ThreadLocal은 어떻게 구현됩니까? (0) | 2020.10.24 |
| scala.collection.mutable.Map에 요소를 추가하는 구문은 무엇입니까? (0) | 2020.10.24 |
| Winform 앱의 기본 버튼 속성 (0) | 2020.10.24 |
| 스칼라는 요소가 목록에 있는지 확인합니다. (0) | 2020.10.24 |