I was wondering, how exactly do these sensors work?
The main problem with this question is that it's extremely, extremely broad, to the point that a textbook full of material would not sufficiently answer it. Every detector at the LHC is built from different types of sensors, and even within each detector, there are many different sub-components, each serving a different purpose and each made of a different type of sensor. If you're looking for specifics, then the best source are the Technical Design Reports (TDRs) for each LHC detector:
The earlier reports are generally more comprehensive, but are also possibly outdated, as whole sections of each detector have been replaced since they were built.
In the most general possible terms, though, detectors are often thought of fulfilling one of two roles: tracking or calorimetry. In order to measure anything about a particle, a detector must be able to interact with that particle, and interacting with the particle means exchanging energy with it and altering its path. A detector designed for tracking and a detector designed for calorimetry have opposite preferences for how much energy to exchange.
Detectors focused on tracking aim to minimize the amount of energy exchange, and alter the path of the particle as little as possible. This is because the data that is extracted from a tracking detector (i.e. the actual path of the particle as it flies out of a collision, from which you can extract the charge/momentum ratio if there's a magnetic field, and possibly more information if the particle decays in-flight) degrades more and more if the detector itself alters the particle's path to any significant extent.
On the other hand, detectors focused on calorimetry aim to maximize the amount of energy transferred to the detector, because that's exactly what they are trying to measure. An ideal calorimeter would be able to completely stop anything that can interact with it, since letting a particle pass through it would mean an incorrect measurement of that particle's energy. Usually a detector incorporates several types of calorimeters, made of different materials that interact with different types of incoming particles, so that in addition to the deposited energy, more information about the particle type is gathered.
All LHC detectors combine some tracking equipment with some calorimetry equipment, since the data gathered from both is enough to measure most of the practical features of a collision.
I assume that the sensors not only have to be extremely sensitive
Not always, or at least, not for all incoming radiation. Most of the "interesting" material exiting collisions is at very high energies, and the goal is to be as efficient and precise as possible when you're measuring interesting material, even if that means a corresponding inability to measure below a certain threshold energy. There's always a tradeoff. For example, a stronger magnetic field in the detector will allow you to measure the curvature of the track (and hence the momentum, and with calorimeter data, the mass and charge) of very high-energy particles more precisely, but it also means that more low-energy particles will get turned around before they ever hit your detector. The difference in design choices regarding this are why the four detectors aren't clones of each other.
but sample at a rate of hundreds of millions of samples per second or even millisecond
The important number here is the bunch crossing rate, which is essentially the spacing of bunches of protons (or other ions) around the ring. Currently, bunches of particles cross at each interaction point (there are 8 of these, 4 of which are used for the detectors) once every 25 ns. The actual collision rate is lower than this, and fluctuates in a time-dependent way; nevertheless, if you want to be able to distinguish between separate bunch crossings, the electronics have to sample at at least 40 MHz (i.e. 1/(25 ns)).
How do they get computer processors fast enough to measure from the sensor that quickly?
As you can see, the sample rate of the electronics actually isn't all that high. The issue instead is bandwidth, in other words, the product of the sample rate and the data per sample. Each collision contains a large amount of data, enough that simply storing every possibly-interesting expected collision becomes impractical from a memory standpoint, and figuring out which data to store and which to discard is the primary job of many, many physicists worldwide (this is usually referred to as the trigger system).
Each experiment handles this problem differently; for details, see the above Technical Design Reports. Often, making this decision at the software level simply isn't fast enough, and custom FPGAs and even ASICs have been designed to quickly throw out cases where it's relatively clear nothing interesting is happening. Since these cases constitute the majority of bunch crossings, this gives the software more time to make a decision.
