Q: "Which trigger will invoke first?"

A: In theory, it is ordered by the creation date of each trigger. However, this is not guaranteed and cannot be controlled programmatically. As far as the developer is concerned, he should code all triggers as if they are running in parallel; changes made by any given trigger will not be visible to other triggers in the same event phase on the same object on the same transaction.

If you must guarantee the order of execution, the three triggers must be rolled into a single trigger. If you need to create silos in order to organize your code, use three different classes, and call each in the order you desire in the single trigger that invokes all three classes.

Q: "Is there any way to stop other 2 triggers after first one invoked?"

A: You can use a static variable in a class. The trigger can check for a specific value in this static variable and return early if the condition is met. However, because of the non-deterministic nature of parallel triggers, you cannot assume that any particular trigger will "execute first." Even if it runs correctly in a developer org, moving the code to a different org, or recompiling, or any other of a number of factors might cause the execution order to change.

You also cannot "yield" in a trigger (in the context of a co-routine, such as Lua or Ruby), so each trigger gets only a single chance to run under normal circumstances (Opportunities might run the same trigger twice, and workflow rules might cause triggers to re-execute).