저는 실시간 응용 프로그램에서 Azure로 작업하고 있습니다.Microsoft Azure의 실시간 응용 프로그램
아이디어는 모든 사용자가 (그들은 서비스의 새로운 정보를 그래서 모든 초를 폴링) 자신과 다른 모든 사용자가 즉시 볼 수 대해 뭔가를보고 있다는 것입니다
이제 웹 역할에 대한 사용하던 대한 나의 접근 방식 작업자 역할없이 DB (SQL Azure)에 대한 모든 작업을 수행하는 WCF REST 서비스. 즉각 작성됩니다.
필자는 작업자 역할과 대기열을 사용하여 쓰기 작업을 확장하는 것이 훨씬 더 확장 적이지만 서비스의 실시간 측면을 방해 할 수 있다고 생각했습니다. (작업자 역할은 대기열에서 즉시 작업을 수행하지 못할 수도 있습니다.)
사실입니까? 이 문제에 대해 어떻게해야합니까?
감사
는 큐가 지연의 비트를 추가하는 것은 사실이지만, 당신은 메시지의 엄청난 양을 처리하기 위해 작업자 역할 인스턴스의 수를 확장 할 수 있습니다.
한 번에 두 개 이상의 메시지를 가져 와서 큐 읽기를 최적화 할 수도 있습니다. 하나의 큐에 500 TPS의 확장 성 목표가 있기 때문에 읽기에 초당 500 개의 메시지를 넘을 수 있습니다.
최신 사용자 업데이트를 버퍼링하기 위해 캐시를 조사 할 수 있으므로 폴링이 발생하면 서비스는 SQL Azure 대신 캐시에서 읽습니다. 이는 정보량이 증가함에 따라 도움이 될 수 있습니다.
SignalR을 살펴볼 수 있으며, 바로 사용할 수있는 팜 시나리오를 지원하지는 않지만 Azure 서비스 버스를 사용하여 내부 끝점 호출을 사용하여 모든 인스턴스를 업데이트 할 수 있어야합니다 , 또는 AppFabric 캐시를 사용합니다. 이렇게하면 Pull 시나리오보다는 Push 시나리오를 얻을 수 있으므로 잠재적 인 업데이트를 위해 끝점을 폴링 할 필요가 없습니다.
그럴 수 있습니다 :) 감사합니다. – Roman