AMQP/ZeroMQ/RabbitMQ를 사용하는 이유
https://stackoverflow.com/questions/1823705
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
자신의 라이브러리를 작성하는 것과는 대조적입니다.
우리는 여기서 자체 분할 서버 풀이 될 프로젝트를 진행하고 있습니다. 한 섹션이 너무 무거워지면 관리자가 이를 분할하여 별도의 프로세스로 다른 시스템에 배치했습니다.또한 이로 인해 영향을 받는 연결된 모든 클라이언트에게 새 서버에 연결하도록 경고합니다.
서버 간, 프로세스 간 통신에 ZeroMQ를 사용하는 방법이 궁금합니다.내 파트너는 스스로 굴리는 것을 선호합니다.저는 이 질문에 답하기 위해 커뮤니티를 찾고 있습니다.
저는 상당히 초보 프로그래머이고 메시징 대기열에 대해 방금 배웠습니다.내가 검색하고 읽은 대로 모든 사람이 모든 종류의 작업에 메시징 대기열을 사용하는 것 같습니다. 그런데 왜 그럴까요?자신의 라이브러리를 작성하는 것보다 더 나은 점은 무엇입니까?왜 그렇게 흔하고 왜 그렇게 많은가요?
해결책
자신의 도서관을 작성하는 것보다 더 나은 이유는 무엇입니까?
앱의 첫 번째 버전을 출시 할 때, 아마도 아무것도 없을 것입니다 : 당신의 요구는 잘 정의되어 있으며, 당신은 당신의 요구에 맞는 메시징 시스템을 개발할 것입니다 : 작은 기능 목록, 작은 소스 코드 등.
그 도구가 있습니다 매우 유용한 ~ 후에 첫 번째 릴리스는 실제로 응용 프로그램을 확장하고 더 많은 기능을 추가해야 할 때. 몇 가지 사용 사례를 알려 드리겠습니다.
- 앱은 Little Endian Machine (x86, Intel/AMD)의 Big Endian Machine (SPARC/PowerPC)과 대화해야합니다. 귀하의 메시징 시스템에는 Endian 주문 가정이 있습니다.
- 이진 프로토콜/메시징 시스템이 아닌 앱을 설계했으며 이제는 대부분의 시간을 구문 분석하는 데 소비하기 때문에 매우 느립니다 (메시지 수가 증가하고 구문 분석이 병목 현상이되었습니다) : 이진을 전송할 수 있도록 적응하십시오. 고정 인코딩
처음에는 LAN 내부에 3 개의 기계가 있었지만 눈에 띄는 모든 것이 모든 기계에 도달하지 않습니다. 클라이언트/보스/Pointy-Haired-Devil-Boss가 나타나서 관리하지 않는 WAN에 앱을 설치한다고 말한 다음 연결 실패, 불량 지연 시간 등이 있습니다. 메시지를 저장하고 재 시도해야합니다. 나중에 : 코드로 돌아가서이 물건을 연결하고 즐기십시오.
전송 된 메시지는 회신이 필요하지만 모든 대답이 필요하지는 않습니다. 매개 변수를 보내고 전송하고 인정하는 대신 결과로 스프레드 시트를 기대하고 코드로 돌아가서이 내용을 연결하고 즐길 수 있습니다.
- 일부 메시지는 중요하며 수신/보내기가 필요합니다. 적절한 백업/지속성/. 왜 묻습니까? 감사 목적
그리고 내가 잊은 다른 많은 사용 사례 ...
당신은 직접 구현할 수 있지만 그렇게하는 데 많은 시간을 할애하지 마십시오. 어쨌든 나중에 교체 할 것입니다.
다른 팁
그것은 묻는 것과 매우 흡사합니다. 왜 자신의 글을 쓸 수있을 때 데이터베이스를 사용합니까?
답은 한동안 주변에 있었고 많은 다른 사용 사례에서 잘 이해되는 도구를 사용하는 것입니다. 시간이 지남에 따라 점점 더 많은 비용을 지불하고 요구 사항이 발전함에 따라입니다. 둘 이상의 개발자가 프로젝트에 참여하는 경우 특히 그렇습니다. 새 프로젝트로 변경하면 대기열 시스템의 지원 직원이되고 싶습니까? 도구를 사용하면 발생하지 않습니다. 다른 사람의 문제가됩니다.
적절한 경우 : 지속성. 디스크에 하나의 메시지를 저장하는 도구를 작성하는 것은 쉽습니다. 스케일링하고 성능이 좋은 끈기를 작성합니다 그리고 안정적으로, 많은 다른 사용 사례에서 관리가 가능하고 지원하기에 저렴한 것은 어렵습니다. 누군가가 얼마나 힘든지에 대해 불평하는 사람을보고 싶다면 이것을 봅니다. http://www.lshift.net/blog/2009/12/07/rabbitmq-at-thet-matter-functramming-exchange
어쨌든, 나는 이것이 도움이되기를 바랍니다. 항상 자신의 도구를 작성하십시오. 많은 사람들이 그렇게했습니다. 문제를 해결하는 것이 무엇이든, 좋습니다.
나는 Zeromq를 직접 사용하는 것을 고려하고 있습니다. 따라서 나는이 질문을 우연히 발견했습니다.
모든 요구 사항을 충족하는 메시지 대기열 시스템을 구현할 수 있다고 가정 해 봅시다. 왜 롤에서 소유 한 접근 방식에 대해 Zeromq (또는 다른 타사 도서관)를 채택 하시겠습니까? 단순 - 비용.
Zeromq가 이미 모든 요구 사항을 충족한다고 잠시 가정 해 봅시다. 해야 할 일은 빌드에 통합하고 DOCO를 읽은 다음 사용을 시작하는 것입니다. 그것은 당신 자신을 굴리는 것보다 훨씬 덜 노력해야합니다. 또한 유지 보수 부담은 다른 회사로 옮겨졌습니다. Zeromq는 무료이므로 Zeromq 팀의 일부를 포함하도록 개발 팀을 성장 시켰습니다.
소프트웨어 개발 사업을 운영 한 경우, 제 3 자 라이브러리 사용의 비용/위험의 균형을 유지하는 것과 균형을 이룰 것이라고 생각합니다.이 경우 Zeromq를 사용하면 손을 내밀겠다고 생각합니다.
아마도 많은 개발자들이하는 것처럼 당신 (또는 당신의 파트너)은 "여기에 발명되지 않았다" 증후군? 그렇다면 태도를 조정하고 Zeromq 사용을 재평가하십시오. 개인적으로, 나는 다른 곳에서 자랑스럽게 찾은 태도의 이점을 선호합니다. 나는 Zeromq를 찾는 것을 자랑스럽게 생각하기를 바라고 있습니다 ... 시간은 말할 것입니다.
편집 : 나는 이것을 발견했다 동영상 이야기하는 Zeromq 개발자로부터 왜 Zeromq를 사용해야합니다.
자신의 라이브러리를 작성하는 것보다 더 나은 점은 무엇입니까?
메시지 큐잉 시스템은 트랜잭션형이므로 개념적으로 클라이언트로 사용하기 쉽지만 구현자로서 올바르게 사용하기는 어렵습니다. 특히 영구 큐를 고려하면 더욱 그렇습니다.빠른 메시징 라이브러리를 작성하면 문제가 해결될 수 있다고 생각할 수도 있지만 트랜잭션과 지속성이 없으면 메시징 시스템의 모든 이점을 누릴 수 없습니다.
이 맥락에서 지속성은 서버가 다운될 경우 메시징 미들웨어가 처리되지 않은 메시지를 영구 저장소(디스크)에 보관한다는 것을 의미합니다.다시 시작한 후에는 메시지를 처리할 수 있으며 재전송이 필요하지 않습니다(발신자는 문제가 있는지조차 모릅니다).트랜잭션이란 트랜잭션 방식으로 여러 큐에서 메시지를 읽고 여러 큐에 메시지를 쓸 수 있다는 의미입니다. 즉, 모든 읽기 및 쓰기가 성공하거나(하나 이상이 실패하는 경우) 아무 것도 성공하지 못합니다.이는 데이터베이스와의 인터페이스에서 알려진 트랜잭션 성과 크게 다르지 않으며 동일한 이점을 갖습니다(오류 처리를 단순화합니다.트랜잭션이 없으면 각 개별 읽기/쓰기가 성공하는지 확인해야 하며, 하나 이상이 실패하면 성공한 변경 사항을 롤백해야 합니다.
자신의 라이브러리를 작성하기 전에 여기에서 0MQ 가이드를 읽으십시오. http://zguide.zeromq.org/page:all
RabbitMQ를 설치하기로 결정하거나 그렇지 않으면 이미 모든 단단한 부분을 수행했기 때문에 ZeromQ 위에 도서관을 만들 것입니다.
약간의 시간이 있다면 시도해보고 자신의 구현을 출시하십시오! 이 운동에 대한 학습은 이미 테스트 된 도서관을 사용하는 지혜에 대해 확신시킬 것입니다.
