All examples I find on the web for using SQL Server Service Broker queues seem to have two queues. I don't understand why and every example seems to assume that this is so obvious as to be unnecessary to explain.
Several things will write to my queue and a stored procedure will read from it and insert to database. Why do I need two queues?
For example: http://www.techrepublic.com/article/use-service-broker-internal-activation-in-sql-server-2005/6156264#
Technically you can use one queue using SSB technology in your application. In this case this queue has a mess from request messages from initiator and response messages from target. Your stored procedure should implement mechanism to distinguish one from another, sort out them, decide which response is for which request and so on. Also take in mind that RECEIVE messages from this queue in exact order and you can't skip some of them and leave in queue for further processing.
Maybe better in your case to follow Remus Rusanu's answer and implement your queue using database table?
SSB idea is simple - Initiator places request message into Target's queue while waiting response message from Target in its own queue. Is it your case? If no, maybe you need not SSB at all?
Service Broker has basically nothing to do with queues. Service Broker is for writing distributed applications, not for queuing. Queues are simply message stores for service, and one service is on one machine while the other service is on a second machine. Examples may show both services in the same database just for simplicity sake, but the example is still about communicating in a distributed environment.
Examples that show case where a single queue apparently is enough are using Service Broker incorrectly. Those examples should better show how to use tables as queues.
来源：https://stackoverflow.com/questions/14643015/why-do-i-need-two-sql-server-service-broker-queues-for-a-simple-task