I am new to Tridion and am confused regarding usage of the Broker database with deployers. I have to configure 2 deployers. One for my Staging site and one for the Live site.
Can I use a single Broker database to store the data from both the deployers?
The reason you need two separate databases (not database servers per se), is because the items you publish to the broker database will be identified by their unique ID, and that does not include the target they were published to.
Which might clarify even further what Nuno states. Now as mentioned by Dylan, you can store both databases on the same database server, but depending on security/access requirements, you might even decide against that. Typically your staging server is accessible only from inside your corporate LAN, while the live server is accessible from the world wide web. If the content you publish to staging is under embargo, then you might not want it on the same database server which is accessible from the world wide web (the server itself of course isn't, but access to the database is).
The title of your question "Can I configure multiple deployer on a single broker database" suggests that you have a scale out scenario where you need to increase the throughput of publishing end-to-end, i.e. 2 Deployers per target.
Staging Deployer 2 -> Staging Broker DB 1
Live Deployer 1 -> Live Broker DB 2
The answer to this is yes with a BUT...
Only 1 Deployer per Publication can write to the Broker at a time. Julian explains here: http://www.julianwraith.com/2012/12/multi-multi-sdl-tridion-deployers-solving-the-race-condition/
So if you have 10 web publications, you can have 10 deployers writing to the same DB where each deployer is responsible for at most 1 publication.
Another scenario is that you can have 2 Deployers per DB (regardless of Publication) for failover. One hot Deployer and one cold. If some critical problem occurs, e.g. app server goes down due to a hardware failure or routine maintenance, the other spare Deployer will be brought up.
No, you can't. Since you intend to use 2 targets (Staging and Live) if you use the same database, it means you have the same data on both targets - which defeats the purpose of having a staging environment altogether.
If you do this, content published to staging so that editors can validate if it looks good would be published to live at the same time... usually this is not a good idea.
Depending on how your environments are set up you could do this, but I wouldn't advise it.
Consider the scenario where you have the Staging and Live site publishing from the same CM. In this case all TCMs would be the same, meaning that many of the entries for Stage and Live would likely overwrite each other. If you are storing content in your database publishing to Stage would likely update that content in Live at the same time, defeating the purpose of having two environments.
If you have your Stage and Live environments separated in the CM the TCMs would be different, but the same item IDs would still be used since Tridion just assigns them in order. This means that some references in Stage and Live could end up conflicting, with completely different items in Stage and Live sharing TCMs and overwriting each other in the CM. This would cause a lot of confusion and could also lead to content being published to Live when it's published to Stage, causing risk to your Live environment.
Bottom line is, this is likely going to be more of a headache than just setting up separate databases.
Taking your statement a single Broker database to put data from both the deployer.. literally it seems you are suggesting
If this is the case then, as Nuno states, this is absolutely not how this is designed and would be recommended against.
I would ask why on earth, if you've invested in an instance of SQL Server (other database solution do exist), would you want to try and merge two databases.
It's perfectly feasible to have - and easy to configure - two different broker databases in one SQL instance.
