Embedding zk in a product is a fine thing. Embedding zk in an application is (in my estimation) a bad idea. The problem is that you generally want to coordinate all the way down to zero, especially in upgrade situations. Combining the uptime constraints of zk with those of your app is bad strategy.
As a concrete example, suppose that you need one or more copy if your software to run and you are running it on 6 machines. Should your zk quorum include all 6 machines? I think not. Now what happens if you want to upgrade? It is plausible that your app will work with only or copy running but you probably would want enough to handle current load during a rolling upgrade. Should that requirement be combined with the need to preserve a zk quorum? What if you have zk on 3 machines and you want to upgrade all three of those in step 1 of a rolling upgrade. Do you really want to make that impossible? Sent from my iPhone On Jul 1, 2013, at 20:22, Kai Lu <[email protected]> wrote: > A lot of applications in big companies had done that already. > > On Jul 1, 2013, at 8:06 PM, 吴靖 <[email protected]> wrote: > >> Hi all: >> >> >> Recently my company want use zk to manage our cluster( For node management >> and HA). But someone in my team want to embed the ZK in our product >> application. But somehow I always feel very odd to embed ZK in. >> Here my question are : Is it a good idea to embed ZK in a product >> application ? >> And dose it work fine in product mode (like overflow memory and other >> problems )? >> >> >> >> thank you ! >> >>
