JGroups ARM (i)

Jgroups/arm (i)
Based on Hein Meling and Alberto Montresor ppt.



Objective



Into the distributed era, we usually define 1 reliable high availability 2 fault tolerant 3 load balancing as the three basic conditions that distributed systems meet. The distributed system does not refer to the operating system it acts as a middleware role, building a bridge between the various operating systems and applications, and it does not rely on specific hardware, software and operating systems, not limited to system architectures and software Systems II, based on the full use of inexpensive hardware and software, Achieve the greatest price/performance ratio.

To further discuss distributed systems, let us understand the challenges that our traditional centralized systems face:

1, server hardware failure (hard drive damage)

2, network failure (switch, router crash)

3, operating system failure (Windows panic)

4, software failure (memory leak)

Distributed systems need to address the problems caused by centralized systems and need to start with the following two

1 provides a system framework that implements multiple data replication between servers and can be automatically recovered without the intervention of the administrator when there is a failure.

2 provides a set of interfaces that allow users to develop reliable, highly available distributed applications on this basis.



Let me look at the past Distributed system framework to

L Corba

L Dcom/.net

L Java RMI/JINI/EJB

These three system frameworks all have the following characteristics

1, Object-oriented

2, based on the idea of Client/server remote method call

3, Modular

4, highly reusable

5, interoperability

6, portability (DCOM limited to Windows platform)



Below, take the Java RMI remote method call as an example to describe the problems of the traditional distributed framework.



Java RMI (remote method invocation) is implemented in a later version of Java in JDK1.1, which greatly enhances the ability of Java to develop distributed applications. RMI is one of the core solutions in a fully pure Java network Distributed Application system, but it can be viewed as a Java version of RPC. However, traditional RPC does not apply well to distributed object system. Java RMI, however, supports communication between program-level objects stored in different address spaces to achieve seamless remote invocation between remote objects. RMI is currently communicating using the Java Remote Message Exchange Protocol (JRMP) (Java sqlremote messaging Protocol). JRMP is a protocol designed specifically for Java remote objects. Application systems developed with Java RMI can be deployed on any platform that supports JRE (Java Run Environment Java, running environment). However, since JRMP is specifically designed for Java objects, RMI has insufficient support for application systems developed in non-Java languages. You cannot communicate with objects that are written in a non-Java language.



RMI lets JVM1 and JVM2 call each other when the details of the underlying operating system are shielded, but if the above schema is changed to a one-to-many model (one client to multiple servers), The client still avoids the need to know the network details of each server on the system (that is, the call to the server is not transparent), and there is a problem with how to maintain call consistency between servers.

In short, distributed frameworks such as RMI and DCOM do not have a good view of reliability and high availability requirements. So a new concept is presented here--the component group (Object group).

A component group can understand this: it is a dynamic collection of server objects and components, in which all component objects in the collection collaborate and maintain consistency across components, providing consistent, reliable, and high-availability services outside the client.

? shape?\* Mergeformat
Client

Server

Server

Server

Server
? shape?\* Mergeformat
Client

Server

Server

Server

Server
The component cluster relies on three services to frame the distributed architecture, and before describing the framework, it is agreed that group (group) is a combination of components that can be abstracted into group members, and that events usually occur in groups:

A) Join

b) Leave

c) Merge

D) Partition

e) Crash



1, Group Management Services (group membership service)

Because the group is dynamic, some members will join (join) to the group, some members will be separated (leave), some team members will be accidentally separated from the failure (crash), sometimes there are 2 groups (merge), separation (Partition), etc. A group must have the ability to handle these events.

2, reliable multicast services (reliable multicast service)

In a distributed group environment, we have a one-to-many approach to achieving high availability (with HA in fact the same concept), and the key now is how our group can communicate reliably.

The answer is simple--multicast. The concept of group multicast can be referred to:

Http://blog.csdn.net/huangzhq/archive/2005/02/18/291761.aspx

3, Status Transfer Service (State Transfer Services)

The purpose of state transmission is to synchronize the information of group members, that is, the structure of Group A and team B is consistent. That is, a group member is using this service to maintain a unified view of the group.